It's written in Go with no dependencies (or database). My intention was for an AWS image or something companies could run inhouse air-gapped from the Internet. Something like $10/m or so.

The cli is pretty easy to integrate with scripts: https://github.com/thisdougb/doocot

Longer term secrets were something I was looking at too. Pretty easy to extend this, but encroaches on Vault products and I felt that a harder sell to CTOs.

I've worked in infra/systems dev for years, and this sort of thing was bread and butter stuff.

Maybe I'll resurect it as an active project. What sort of feature/tool would get you to stop using Discord/Slack/etc for secrets?

An integrated solution for the whole environment. I pick a project, it opens the IDE, sets environment variables, fires up other services/infrastructure, lets me select secrets (that might be shared between projects), lets me share secrets (with other people)... Probably something like tilt, but simpler, integrated into an IDE, and with support for secrets.

There's a VSCode extension for Hashi Vault: https://marketplace.visualstudio.com/items?itemName=owenfarr... for secrets management, but it's complicated because Vault is complicated.

A secrets extensions for my backend app would be quite easy though, I think. It's just re-implementing the cli tool.

From the IDE command palatte you could:

- Settings.backend_host = private Doocot backend || public backend

- Settings.username = (automatic)

- Settings.identity = (automatic) something like ssh key data

- Share.Individual = "select from list of identities on backend"

- Share.Group = "select from list of groups I am in"

- Share.Link = "store secret and return a valid one-time url for a non-dev"

- Read.SharedSecrets = "list secrets shared to me or my groups"

Then it'd just be some thought into the simplest way to setup and maintain groups.

You've piqued my interest in it again though, as it doesn't seem much extra work to do the above. Given the backend more or less does most of it already.

Although it's not the full environment integrated solution you're looking for, I think one step forward in terms of how we share secrets is still useful.

Thanks

(1) someone always pays

I have a vm I connect into via ShellFish (same dev as Working Copy) for when I want to checkout/fix/deploy, but it's a rarity that I need to do that.

"In this episode we explore the “Climategate” scandal that erupted from leaked emails and code snippets, fueling doubts about climate science. What starts as an investigation into accusations of fraud leads to an unexpected journey through the messy reality of data science, legacy code struggles, and the complex pressures scientists face every day."

He goes into the code/data that is seemingly the root-cause of a lot of "it's all a hoax." I found it pretty informative, as to how climate data is gathered and processed (by the scientists). And the limitations therein. He's simply trying to explain the cause of climategate, rather than advocate any view.

It's also a great example of a tech/dev investigation into root-cause analysis, of someone else's code. So it's interesting from that point of view, even if you're less interested the climate side of it.

Static site generators take input, run it through templates, and produce html output. This seems to be, literally, what you want to do. Maybe try and implement what you want and you'll see they can do it.

I use Hugo to generate some static pages that sit inside a dynamic website. It's just Go templating, which is not too hard to learn. You can create individual pages that pull in multiple templates if you want. You can switch off RSS, change naming from posts to bananas, etc. Very few preconceived regulations.

Most of the static generators are used for blogs, that's probably why most examples they give are around blog posts. It doesn't mean the name 'post' actually means anything special.

I'm really interested in the additional time cost of your switch. As you say, measuring productivity is seems nearly impossible.

But I would expect your 40 developers now have more time to do other things, because AI is taking on some of the workload? So have you noticed developers now doing 'new' things, like experimenting with new ideas, shorter hours, more holidays, or spending more time learning non-core topics? I think that would be visible. The 'Friday for personal projects' becomes 'Thu and Fri for personal projects', for example.

When frameworks became popular ten or so years ago, developers made the 'this will be much more efficient' argument. All that seemed to happen was the time they used to spend thinking/learning the core language (or engineering concepts) was swapped for time learning the framework. So there was no significant productivity gain, despite tasks feeling easier to do.

You list AI management/maintenance tasks that didn't need to be done before. I assume not all of these are 40x across your developers. It will be interesting to see if this management workload becomes similar to infrastructure management, and develops into a new job type providing a shared service. At least maybe during the transition away from flesh-based development to AI development.

I guess your end goal is that AI writes all (literal) code and owns the codebase, directed by people in the company? Do you have a plan to transition developers away from tech roles, is that something that's discussed?

I think he's doing an AI YouTube channel. He was quite rational with all the nosql hype back in the day, and seems to still be quite rational.

A few days ago I spent an hour trying to get Claude to write unit tests for a relatively simple function, without getting anything functional in return. It produced good (but changing) plans of work, but the code generated didn't match the plan (syntax or semantics).

Are people simply replacing 'time spent coding' with 'time spent mentoring AI'? And is that a useful trade off, given AI forgets everything?

I'd love to see a more honest discussion about the overhead of coding with AI assistance. It's still too high an overhead for me at the present capability.

This point is so underrated, when discussing about replacing junior devs with AI.

If you're trying to build a business, only a small part of it is about generating code. Sticking with it and developing a good product is where you make the difference. I've built many things in a couple of weeks of coding, but then given up when faced with the hard work of making it a solid business.

My other thought is.. There are always others coding faster than me, writing better web copy, doing sales more successfully, etc. You/we pick AI as a threat because we understand it, but a good sales person is just as much of a threat to your idea.

We all have technical/skills advantages and disadvantages. In the successful startups I worked in these were not that important in the end. It was just about keeping going, every day. Relentless optimisim that you're right.

this is a great insight. never thought of it that way. thanks so much

Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.

Specs were never frozen with waterfall.

I know Python, but have been coding in Go for the last few years. So I'm thinking how I'd implement this in Go.

There's a lot of code there. Do you think it's a lot, or it doesn't matter? It seems reasonably clear though, easy to understand.

I'd have expected better documentation/in-line comments. Is that something that you did/didn't specify?

I really wanted to see how far I can get with that approach.

I will ask it to clean up the code and its comments and report back.