liampulles
No we can't call the CRM from our client side using a static bearer token even though their docs say we can. No we can't simply switch to Postgres even though it supports 99% of the same SQL we currently use. No we can't simply block usernames which are "clearly" profane.
But if we can chat about it, then we can see what the REAL problem is, and then we can come up with a fitting and simple solution.
The problem is that I have an AI colleague who is way more energetic and willing than I am. They love to talk, they seem to ramble on endlessly about any subject. And its the kind of solution oriented talk my PM loves to hear. And indeed my <insert senior role here> talks to them (or really, lets them talk), and draws up a comprehensive and confident plan to do X. I pick up the plan and discover problems with X, let alone the plan to do it.
I feel nervous about raising issues with X or going through the plan again though, because my other human colleagues are already speeding through the work for Y and Z that my AI colleague is aiding with.
And so maybe I'll raise my biggest concerns with X and not sweat the small stuff. Maybe next time I won't raise my neck at all, noting the gleaming axe sitting in the corner.
* The IT crowd season 1 had leetspeak and base64 encoded subtitles (won't spoil what the encoding decodes to).
* Goodfellas has a commentary track with the central criminal and the FBI agent who arrested him.
* The Simpsons (around season 9 if I recall) has a hidden commentary track (not accessable by menus) where two of the writers fairly candidly explain the quality dip that was to follow, and have an impromptu phone call with the illusive John Swartzwelder.
So no, I don't want animated menus or worthless features. Put a commentary track - that has high extra value to size ratio - but leave it to that.
At least this is my observation: when my colleagues have been wholesale chucking stuff over to Claude, they've then been confronted with classic XY-Problem shit, poor user experiences, and over-complex solutions (which will mount future problems regardless of whether a person or an agent iterates on that code). Much of this can be solved by actually sitting down and thinking about it, and I mean at a code design level, not just a speccing level.
Many people don't realize that there are more useful outputs to solving a problem than just a mere solution. Obviously if one has a contractor mindset (you don't care about the after effects of a system) then this is of no relevance to you. Some companies promote that mindset, certainly ones that have no broader aspirations then getting acquired soon. That's fine - but many companies actually are about sustainability, and understanding in these places is paramount.
Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course - Java can be used to write great software. The problem is that in Java there exist an extraordinary set of variations of a sufficient implementation, many of which are package protected abstract static horrors shows. And that will manifest over time if you add different individual developers. Else the project must engage in bureaucracy and control, where you have meetings over style conventions or hardline architects who come to constrain the joy of programming in the devs.
Its much better when the language itself constrains you, then everyone can just move on. I feel Go, though certainly not perfect, meets this niche.
At least one of those things is missing here.
Then I can do stuff to the XLSX with Claude, and work on the spreadsheet in my spreadsheet editor.
What I DONT want is for my office suite to have any limiting AI features built in.
Specifically, the idea of putting toggles on risky functionality is a good idea that is useful broadly. Being able to dynamically toggle feature flags without a restart, or apply some features to some segment of users is unlikely to be useful and entails a lot of complexity and potential footguns.
My approach to feature flags is even simpler than what is suggested here: feature flags are just a section in your config. Done. Even if you are confident that you need more advanced capabilities, you should not "advance" to that level until you have demonstrable proof that your team can manage simple config values for it.
Almost no one else except the PC gamers I know really like using desktop (or laptop) computers. Most people love being able to sit on the couch and use apps on their phone. Its not like massive portions of the population were loving their desktops until smartphones arrived and they transitioned, no - smartphones are what helped the internet revolution really inseminate into the general population.
I use Claude plan mode to do relatively small changes and even then I find that if I actually try and think through the problem and solve it myself that I find good metaphors that will aid future work, and I will discover tangential issues which are then important to look at.
I try to take the mindset of "continuous crap reduction". I let go of the things that are out of my control, and seek to reduce the biggest problems that are in my control. Then I can get a "win" every day, and I don't try and fight the stuff out of my control which is only a little crap. I have to try and be principled without being opinionated.
The problem comes later when the code no longer reveals the domain and the processes of the business, and where changes start affecting other expected business behaviors (at least that is what I think would happen, I find the code too distasteful to let it get that far).
Yes, that's partly a sense of qualified taste I've built through experience, but I think it also comes from trying to actually understand user needs better. E.g. Our finance department says they wants a daily report of invoices, but what do they ACTUALLY NEED? Maybe the problem to solve is to allow more flexibility with billing dates, or increase billing strike attempts, etc. That stuff sometimes doesn't come out until you really ask because of all sorts of organizational and social beliefs, fears, etc. Practicing that and recognizing the signs means you can do that rethinking earlier on in the process, before dev starts.
I'm lucky I guess that I've had enough time in this career to experience these moments, and enough experience to know which code I should write and which code really is rote and can be generated (most of the time). Hopefully it keeps the loss of enlightenment to a minimum.