dig into the repo and you'll find libraries of opentofu that are quite opinionated - the point of the plugin is to inject opinions that the agents don't have.
This is one of the biggest benefits. I'm not a plugin user so I don't remember how they're different from skills. Not speaking about the tool in OP specifically but regarding skills in general: you can have essentially the entire task or some of its subtasks (which you'd ordinarily direct to the agent using the skill, the main benefit of which are clearer natural language directions) handled with assistive tools written in any language your environment supports. You can additionally supply the skill with its own config files, data files, etc., building essentially a small repo within particular skills and making these resources however closely tied to the skill as you prefer.
This is particularly useful when the agent would otherwise be doing a task that is programmable, or the agent is inconsistent or unable to do it in an efficient, performant or other preferred manner. The programmatic tool assistance means at least some parts of the task (possibly its entirety) could be handled in a well-tested and deterministic manner. How reliable the determinism, optimality, etc. are depends on how well you or the agent writes and verifies the code, tests, spec, etc. in the first place of course, but that only needs to be done correctly once.
The other great benefit is reduced token use, potentially a massive reduction. Imagine a task Claude takes 10 minutes to prepare to do because it's reading and analyzing files for the 3rd time in the last 4 minutes, then it's asking for permissions several times in between to do this and that even after you put it in auto mode, then it's "thinking" again for the thousandth time about how to approach the task even though you had it repeat the task a hundred times already...by the time it actually starts doing the task, the most recent models are likely to have churned through tens of thousands of tokens (and that's a conservative estimate for frontier models) in the first 10 minutes. But, with tool assistance, you can have Claude directly handle some parts of that same task which, for example, needs unpredictable analysis or decision-making each time, but also have it use a set of highly optimized programs to handle the bottleneck parts or the parts you want done "your way." You could potentially cut down those 10 minutes of prep time + whatever minutes to actually do the task down to seconds, with barely a couple of thousand tokens used up. Just an example of course, but I've benefited from this strategy repeatedly across various tasks, simple or very complex.
Another great thing is that the tools don't have to be tied to the skill at all, they can live anywhere in your codebase. You could even manually run the scripts to handle certain tasks in their entirety or do the prep work before setting an agent loose on the remainder. There are many different approaches with different advantages. It's like actually using the agent as your...well, agent! But now you're supplying him with the latest gadgets like M/Q does for 007.
It does sound cool and as an infra nerd myself it reads sensible, I just don't see why I would want another abstraction layer between my cloud deployments being rolled out and the tf/hcl files that I maintain. Why would I want to install another interface between me, the planfile and the running environment? Genuine question
It’s opinionated and built around a reference architecture- think it kind of like using rails or phoenix instead of just writing ruby or elixir. LLM’s are fantastic syntax generators, but they have no real opinions on architecture or finops.
Oh so more an orchestration interface with sane defaults for an LLM to use as a reference when implementing deployment changes, especially new rollouts?
It seems to be aimed at small to medium sized cloud deployments and more as a starting point to get customers up and running?
Because I'm already administratrating a large AWS environment and the networking, especially as regards route tables, transit gateways, DMZs and extensive security group rules managed in multiple distinct layers across teams (and don't even get me started on IAM and Active Directory Forest) don't seem to fit into the abstraction layer I'm seeing.
Exactly - and it's pretty much aimed at 'built this cool TS app on vercel and supabase and want to scale it' or the like. I build my career migrating rails apps off heroku, and this is kind of inspired by a lot of what I learned.
Are you using IaC to administer all of this or just handjamming in the console? I'd love to expand neckbeard to handle more complex enterprise motions - the landing zone scenario your speaking of is particularly an interesting use case, I'll start thinking on it!
Oh that's neat. Yeah I got started on heroku too. Fly.io also comes to mind.
We run our own gitlab instance in a central AWS account that has some infra buckets containing modularized Terraform packaged into tarballs that are then fanned out to a couple hundred aws accounts across the teams and environments (prod, qual, dev).
Its all deployed via gitlab ci cd pipelines (which are just ec2 instances spawned at pipeline invocation) in multiple layers. The first layer is a foundation laying the networking rules and the IAM roles, permissions, policies and boundaries, some logging and monitoring.
The second layer then assigns team specifics such as budget and maps people's accounts to roles depending on their access level (maintainer, developer, reporter). This layer can also be used to customize firewall rules like opening ports to the company internal IP ranges. The third and final layer is then all of the application infrastructure of the teams, so all their persistence, compute, load balancing, dns routing and serverless stuff. My prior teammates did a lot by hand in the aws console but I told them to stop and retain everything as IaC code. Besides Terraform, in my team we use Packer to build reusable "golden" machine images but also Ansible to configure live machines.
I'm still surprised nobody bothered us to change to Opentofu, it's not even been mentioned yet lol.
Hetzner is awesome, I prefer it to aws for personal projects, feel free to analyze my modularized instance setup with an LLM and rip out what you need, it's all hand built, most of the engineering went into cloud-init and network security - before machines could generate the same in hours lul
The guy in the image doesn't look very euphoric, not even in a subtle way. Sorry, not the neckbeard plugin I was looking for. Mine must be influenced by aalewis.
Write it in English to the best of your ability and then use it with a prompt along the lines of...
Identify parts of the following readme that need to be looked at for consistency, tone, grammar, punctuation, and capitalization issues.
This is to be a readme file for a project on GitHub used by technical people who are familiar with any jargon being used.
Suggest any changes to those by identifying the full passage the fix is in along with the correction.
Note that this works to identify the issues and have you change them to what would be correct for what you're writing without having it do the writing for you and inserting the "claudisms".
I was hoping I was the DevOps/Platform/SRE plugin for my agents!
Humor is what keeps me going too lol
Can this be used with the ponytail skill? https://github.com/DietrichGebert/ponytail/tree/main
It should be compatible yeah - ponytail was the inspiration for this - ideally one could use ponytail for application code and neckbeard for infra.
Also:
suspenders, for resilience
unixbeard, for documentation
roundglasses, for observation
dnd, for chaos testing
I'm not sure if this is a joke or not
please, is it?
Why do you need a plug-in for this? You can just ask the agents to do all this stuff and it works fine in my experience.
dig into the repo and you'll find libraries of opentofu that are quite opinionated - the point of the plugin is to inject opinions that the agents don't have.
I guess it makes the behavior more predictable?
This is one of the biggest benefits. I'm not a plugin user so I don't remember how they're different from skills. Not speaking about the tool in OP specifically but regarding skills in general: you can have essentially the entire task or some of its subtasks (which you'd ordinarily direct to the agent using the skill, the main benefit of which are clearer natural language directions) handled with assistive tools written in any language your environment supports. You can additionally supply the skill with its own config files, data files, etc., building essentially a small repo within particular skills and making these resources however closely tied to the skill as you prefer.
This is particularly useful when the agent would otherwise be doing a task that is programmable, or the agent is inconsistent or unable to do it in an efficient, performant or other preferred manner. The programmatic tool assistance means at least some parts of the task (possibly its entirety) could be handled in a well-tested and deterministic manner. How reliable the determinism, optimality, etc. are depends on how well you or the agent writes and verifies the code, tests, spec, etc. in the first place of course, but that only needs to be done correctly once.
The other great benefit is reduced token use, potentially a massive reduction. Imagine a task Claude takes 10 minutes to prepare to do because it's reading and analyzing files for the 3rd time in the last 4 minutes, then it's asking for permissions several times in between to do this and that even after you put it in auto mode, then it's "thinking" again for the thousandth time about how to approach the task even though you had it repeat the task a hundred times already...by the time it actually starts doing the task, the most recent models are likely to have churned through tens of thousands of tokens (and that's a conservative estimate for frontier models) in the first 10 minutes. But, with tool assistance, you can have Claude directly handle some parts of that same task which, for example, needs unpredictable analysis or decision-making each time, but also have it use a set of highly optimized programs to handle the bottleneck parts or the parts you want done "your way." You could potentially cut down those 10 minutes of prep time + whatever minutes to actually do the task down to seconds, with barely a couple of thousand tokens used up. Just an example of course, but I've benefited from this strategy repeatedly across various tasks, simple or very complex.
Another great thing is that the tools don't have to be tied to the skill at all, they can live anywhere in your codebase. You could even manually run the scripts to handle certain tasks in their entirety or do the prep work before setting an agent loose on the remainder. There are many different approaches with different advantages. It's like actually using the agent as your...well, agent! But now you're supplying him with the latest gadgets like M/Q does for 007.
Plugins are just a collection of prompts & shell scripts.
It does sound cool and as an infra nerd myself it reads sensible, I just don't see why I would want another abstraction layer between my cloud deployments being rolled out and the tf/hcl files that I maintain. Why would I want to install another interface between me, the planfile and the running environment? Genuine question
It’s opinionated and built around a reference architecture- think it kind of like using rails or phoenix instead of just writing ruby or elixir. LLM’s are fantastic syntax generators, but they have no real opinions on architecture or finops.
Oh so more an orchestration interface with sane defaults for an LLM to use as a reference when implementing deployment changes, especially new rollouts? It seems to be aimed at small to medium sized cloud deployments and more as a starting point to get customers up and running?
Because I'm already administratrating a large AWS environment and the networking, especially as regards route tables, transit gateways, DMZs and extensive security group rules managed in multiple distinct layers across teams (and don't even get me started on IAM and Active Directory Forest) don't seem to fit into the abstraction layer I'm seeing.
Exactly - and it's pretty much aimed at 'built this cool TS app on vercel and supabase and want to scale it' or the like. I build my career migrating rails apps off heroku, and this is kind of inspired by a lot of what I learned.
Are you using IaC to administer all of this or just handjamming in the console? I'd love to expand neckbeard to handle more complex enterprise motions - the landing zone scenario your speaking of is particularly an interesting use case, I'll start thinking on it!
Oh that's neat. Yeah I got started on heroku too. Fly.io also comes to mind.
We run our own gitlab instance in a central AWS account that has some infra buckets containing modularized Terraform packaged into tarballs that are then fanned out to a couple hundred aws accounts across the teams and environments (prod, qual, dev).
Its all deployed via gitlab ci cd pipelines (which are just ec2 instances spawned at pipeline invocation) in multiple layers. The first layer is a foundation laying the networking rules and the IAM roles, permissions, policies and boundaries, some logging and monitoring. The second layer then assigns team specifics such as budget and maps people's accounts to roles depending on their access level (maintainer, developer, reporter). This layer can also be used to customize firewall rules like opening ports to the company internal IP ranges. The third and final layer is then all of the application infrastructure of the teams, so all their persistence, compute, load balancing, dns routing and serverless stuff. My prior teammates did a lot by hand in the aws console but I told them to stop and retain everything as IaC code. Besides Terraform, in my team we use Packer to build reusable "golden" machine images but also Ansible to configure live machines.
I'm still surprised nobody bothered us to change to Opentofu, it's not even been mentioned yet lol.
I've worked in similar shops - I'm a big fan of less pipelines and layers and more environment variables.
The real Gilfoyle would self-host.
do as neckbeard says, not as neckbeard does.
> The same reference app (HTTP service + worker + cron + Postgres), smallest tier, all three environments, live prices via Infracost:
Hetnzer server for 25usd/month and you have plenty more space to do more stuff and scale
Hetnzer is next on my list to add! Feel free to PR it if you're feeling froggy!
Hetzner is awesome, I prefer it to aws for personal projects, feel free to analyze my modularized instance setup with an LLM and rip out what you need, it's all hand built, most of the engineering went into cloud-init and network security - before machines could generate the same in hours lul
https://github.com/fiscalismia/fiscalismia-infrastructure/tr...
killer! will take a look - I need a digital ocean alternative.
Yep. I run a lot of stuff of my local datacenter $6/mo hetzner VPS.
This seems like a great way to wake up and have your cloud spend skyrocket because an LLM assumed wrong.
did you read the part where it doesn't let the LLM do that?
Why not opentofu and ansible? Version and run it. I don’t see why i need this.
If you write your own tofu and use ansible you probably don’t - this is aimed more at containers/serverless.
Sometimes the name of a product makes me want to use it, even if I don’t have uses for it. This is such a name, I just keep on grinning.
This makes my day - I genuinely love naming things, as an artist and a technologist it's fun to inject some creativity into the code!
The beard is the wrong color, but otherwise: agree.
I have the opposite feeling about CoackroachDB. Great database, but man, what a terrible name.
Something to try for sure. Company recently migrated some ancient on prem databases to AWS, would've been useful then perhaps.
Thanks! Give it a try next time you need to provision infra.
The guy in the image doesn't look very euphoric, not even in a subtle way. Sorry, not the neckbeard plugin I was looking for. Mine must be influenced by aalewis.
the readme is cringe and painful to read. please take a minute to tone the claudisms down.
definitely on my todo list - I was educated in the American south so you might regret this!
Write it in English to the best of your ability and then use it with a prompt along the lines of...
Note that this works to identify the issues and have you change them to what would be correct for what you're writing without having it do the writing for you and inserting the "claudisms".I usually tell it to write like Anthony Bourdain if he was a high school dropout who taught himself python when he was 14.
I doubt it, bad grammar is better than AI-speak.
we southerners prefer 'colorful' or 'alternative' grammar :)