> I have never felt like a bigger fraud in this field
I'm the most senior software developer in my company and I sit in the middle of the room with my screens open to everyone, and I use 10x the average tokens. I've felt like an imposter when I was barely measuring up against the intellectual giants in my first jobs. It's a feeling, and it has nothing to do with you, your work, or your automation tools.
Secrecy leads to bad patterns of practice. AI doesn't make good programmers bad, or bad programmers good.
Addressing the lack of fun:
> I’m privileged that I get to have fun at all in my line of work
> this has sucked out all of the fun
Split your coding in two: The part that gets done quick, and the part where you personally care about every line of code.
This was always a problem with commercial programming for me: Employer only cares that it gets done, I care that it's good. The tension is necessary.
There are aspects to your style of craftsmanship that the AI hasn't encoded yet.
I choose to embed those in templates and agent skills, but you can also just keep writing that code yourself.
Addressing productivity:
> I would not have the mental capacity or skill to create a pull request like that without AI tooling
> Now that using AI is a normal expectation at work and how I’m evaluated in performance reviews, I suspect that this fraud feeling will only grow
I think that's why using it is so unavoidable: It does increase productivity and lowers cognitive strain, at the cost of yolo.
I don't know if "fraud feeling" is referring to your impostor syndrome, and you want to get rid of this: deal with the feeling, it's just part of your growth as a person. Or if you're using fraud as a loaded term to devalue AI use in programming for ideological reasons: Can't help here, I don't have a problem with it.
Addressing craftsmanship:
> no matter how big the impact, I feel empty
> I still contributed something of value
> I perhaps tied my identity too much to my career
> I’m not the greatest engineer, but I’ve always worked hard
> I care about the craftsmanship of my code
Your interest in the details of your craft will disappear eventually.
Keep it up as long as you care, it's fun.
When you're ready to see yourself as something else, it will naturally fade.
I've been an aspiring team lead without a team for a long time. Now I have a team of robots (and incidentally a team of people), and it feels natural. I still code in my spare time, but not for productivity, only when I have to or when I want to have fun.
For me, I've slowly switched to wanting things to exist rather than wanting to make them. That helps swallowing that I don't code as much any more. (I mean, I still recreatively code 2-3 hours per day, but it's far from the 8-16 hours that have been the norm in my life.)
If it helps: It is probably good for your physical well-being that you don't have to sit hunched over as much.
> Split your coding in two: The part that gets done quick, and the part where you personally care about every line of code.
> This was always a problem with commercial programming for me: Employer only cares that it gets done, I care that it's good. The tension is necessary.
Use AI-assisted coding to MVP or vertical slice or however you want to call it. Prove that it works and is doable. Now you have baseline to start editing from, rewrite every single line, even the ones with just a single { if that's how you roll.
Or read it and ship it as is. Maybe adjust the agent's instructions and the project linters/formatters to match your specific style better.
As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows.
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process.
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
oh yeah AI realy does not seem to actually know which packages exist. I once asked AI to create a devenv for some Julia development and it pulled some packages out of its ass that just plain did not exist.
I've been trying to get nixd LSP to work with Claude Code but I got stuck as they gatekeep it behind their "plugin" system and you can't just configure it in settings.json to point to a nix store path like mcps :(
My usual solution is to just clone whatever I need. e.g. in this case just clone nixpkgs and put in your instructions that it should do a git pull to make sure it's up to date and then refer to that whenever doing anything with nix. Agents are really good at using grep to explore repos even for something completely internal. Then you don't need any config or special tools. e.g. for work I just have a directory with like 30 repos cloned and my base AGENTS file I use says to refer to either them or live system state for ground truth. I basically never encounter hallucinations.
Same goes for the harness itself. Want to know how Codex works or whether it can be configured in some way? Clone it and ask it to look at itself.
I got a gaming computer during covid and initially ran Windows on it. It had so many problems with the audio and random crashes I eventually gave up and switched to Linux. Only loss was the newer Blizzard games, all the Steam games worked.
For a beautiful 6 months before the frontier labs were able to search as part of their responses, Kagi had an edge here. This was when the “AIs hallucinate!” meme was thriving and my response was “Wait, your AI AGENT doesn’t provide references?” and I felt very cutting edge then.
Now that frontier labs have search, generalised tool use, memory, I no longer use The Agent. Haven’t done so for months. I still find great value in Kagi’s FastGPT even though this overlaps with many search engines today. It works well and I don’t pay with my privacy. But there’s no Agent edge any more, Claude wins.
I think it's easier for good engineers to be good, perhaps. For example, I think property testing is "good" engineering. But I suspect that if you took a survey of developers the vast majority would not actually know what property testing is. So is AI really of any use then for those devs?
Internet enabled instant to access to all human knowledge as well as instant chit-chat across the globe. Guess what humanity choose to drown itself in?
So combine both facts here in context, with human nature, and you ll see where this will go.
I think it depends on your process. Problems that require creative solutions are often solved through the act of doing. For me, it's the act of writing code itself that ignites the pathways and neural connections that I've built up in my brain over the years. Using AI circumvents that process, and those brain circuits go unused.
I love that I don’t have to look thru SO looking for a problem that’s kind of like the one I’m having. I have a problem solved based on my exact code taking my entire code base into account. And if I want a biting sarcastic review of my many faults as a software developer, I can ask for that too.
I have, in the last month, resorted to searching StackOverflow for something that works when Claude perpetually got it wrong three times in a row. It felt nostalgic that the answer was there in plain sight, and it just kept trying other things. So searching StackOverflow isn't quite dead yet.
Of course I still have times when Claude fumbles the fix. But the number of times it gets it exactly right far outnumber the times it can't get right. Compare that to the number of SO issues I've had to go through to get near a solution is night and day.
I'm in no way saying you should work the way I do or that Claude would solve all your problems if you only just believe. I am saying it's been super helpful at squashing bugs for me in my circumstances with my code bases.
> Your intent is 'Getting more users by lowering barriers to sign up', a business goal.
Important point.
But it says more about OP’s perspective on product-driven development than this “contextual commits”.
The idea that OP does not follow up on is whether these codified commit messages with a very shallow summary of the LLM context improve anything compared to the normal commit messages that Claude will generate.
I suspect they’re equally insufficient since even a compacted context seems less diffusing and it’s still a lot bigger than these.
> I wish our profession would stop trying to reinvent issue tracking in git every week.
I would love to have good git-powered issue tracking. I haven’t seen it yet.
Proper escaping of layered syntaxes in Ansible on the first attempt
Writing bare-metal embedded Rust, although this was long ago, so not current models
reply