publish init script blog post

app/priv/blog/engineering/2026/05-14-generate-an-init-script-to-get-your-team-up-and-running.md

@@ -1,69 +1,57 @@
 %{
   title: "Generate an init script to get you(r team) up and running",
   author: "Willem van den Ende",
-  tags: ~w(pi.dev AI continuous-delivery),
+  tags: ~w(pi.dev AI deterministic continuous-delivery),
-  description: "Checking out a repository on a fresh machine often involves some fiddling around. An init scripts costs only one prompt and gets you going now, and months later when you forgot about how you set up the project.",
+  description: "Checking out a repository on a fresh machine often involves some fiddling around. An init scripts costs only one prompt and gets you going now, and months later.",
   published: true
 }
 ---
 
-# init script made by qwen 3.6 / Pi
+I like to hit the ground running when starting work in a repository. And I want my colleagues to get up and running quickly as well. 
+One thing I picked up from Anthropics [Harnesses for long running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) last November was creating an ~init~ script that sets everything up in a runnable and testable state. 
 
-I had firehose running on another laptop already, but I added a library for syntax highlighting code
+Run the script, get to work. It only costs one prompt, once, to make, and every time after that is deterministic and fast. 
 
-init.sh script in the repository . The escape codes for ’the server will be on:’ are Cyan color. I removed that by hand.
+It is one of those things where I go: "Why didn't I think of that before?". And an un-metered, local, model is powerful enough to do it while I do something else. It only took two minutes, so not too bad.
 
-    Finished in 1.9 seconds (1.7s async, 0.1s sync)
+## Why make an init script for Firehose (this blog) now?
-    157 tests, 0 failures
+
-    [  OK  ]  All tests passed.
+The best time to make an init script is when you start the project. The second best time is now. 
-    ==============================================
+
-      🎉 Firehose is ready to go!
+I had Firehose running on another machine already. Running one command is usually enough to set up a Phoenix Liveview project, but I had just added another javascript dependency that was not covered by that. So instead of adding that by hand, and figuring out how to do that, I improved the process by adding the init script now.
-    ==============================================
+
-    
+I know now that it pays off very quickly. I had just used another project that had an init script on a new machine. No need to remember, it just works. I like software that "just works".
-      Useful commands:
+
-    
+It is very satisfying when it runs, as you get an overview of next steps you can take. I like 'micro prompts' like these. And it paid of immediately, I will explain after the screenshot.
-        make test          Run the full test suite
+
-        make check         Static analysis (credo + format)
+![Screenshot of a successful run. Shows 157 tests passed, useful make commands, how to start the dev server, what the demo user / password is and the port on which it runs](/images/blog/2026/init-script-result.png)
-        make compile       Compile the project
+
-        make format        Format all code
+
-    
+When I started the server, the port was already taken. As the script outputs the PORT variable, I knew immediately what to do, set the port and got to work.
-      Start the dev server:
+
-    
+Aside: starting the server is now muscle memory for me, and standard in Phoenix Liveview, no need to script, although the generated init script does have a `--server` option for those who don't know. Executable documentation for the win.
-        cd app && mix phx.server
-    
-      The server will be on:  \033[0;36mhttp://localhost:8056\033[0m
-    
-      Demo user (created by seed):
-        email:  demo@example.com
-        pass:   password123!
-    
-      Database:  firehose_dev  (PostgreSQL on localhost)
-    
-      Port:      8056  (override with PORT=xxxx)
 
-It is great to have a script that gets the repo ready for work. 
 
 This was one fairly lazy prompt:
 
 > I think it would be handy to have an init script for this repository that also downloads the js dependencies. the init.sh script should get the dependencies, run the mix setup so there is a working db, run the tests and download the js assets. the goal  
 > is for an agent or a person to be able to start working. At the end of the script, print handy instructions e.g. to run make, and what PORT the server will run on                                                                                            
 
-It only took this prompt. I aborted it after I got a my `turn-limit` extension asked if I wanted to give it more than 25 turns. The agent was done, but couldnt’ actually run the init script because the sandbox does not give it sufficient permissions to do so.
+It only took this prompt. It did take quite a few turns. My Pi turn-limit extension alerted me that it had gone over 25 turns. I chose not to let Pi run further. What happened was that the agent was done, but it did not have permissions to actually run the init script because the sandbox did not allow everything in it. So I ran that by hand outside the sandbox. 
 
-I was using another project I hadn’t run in a months on a machine I hadn’t yet used it on. That project had an `init.sh` script, and got me going in a minute.
+Do you have init scripts or something like it? Would it be useful to you? What do you think?
 
 
-<a id="orgb048805"></a>
-
 ## Further reading
 
-A Full ;-), [very brief transcript](`/images/blog/2026/transcripts/make-init-script.html`). 
+A Full ;-), [very brief transcript](`/images/blog/2026/transcripts/make-init-script.html`) of the session, so you can see all the turns taken in detail. 
-Done. Here&rsquo;s what init.sh does:                                                                                                                                                                                                                              
+
+I wrote earlier on the QWAN blog about working deterministically where possible, and the pay-offs in [Stochastic to Deterministic](https://www.qwan.eu/2025/12/11/stochastic-to-deterministic.html). Even though my local model is un-metered, running a script is still a lot faster and much more predictable.
+
+I used the 35B model from [my local agentic dev setup](/blog/engineering/my-local-agentic-dev-setup-today) It was more than up to the job. Sandboxing is a bit of work though.
 
 
-<a id="org38c2e5c"></a>
+## Bonus item - what the init script does, and local agent performance
-
-## Bonus item - what the init script does, and performance
 
 According to the agent:
 
@@ -74,7 +62,7 @@ According to the agent:
 5.  mix assets.setup && mix assets.build — installs esbuild/tailwind and bundles the JS/CSS
 6.  make test — runs the full test suite
 
-Ends with a summary showing how to start the server (port 8056), demo credentials, and handy make commands.                                                                                                                                                  
+It ends with a summary showing how to start the server (port 8056), demo credentials, and handy make commands.                                                                                                                                                  
 
 The snippet below is from my performance widget. Token generation is not super fast, but all 32 turns ran while attending Chris Parsons&rsquo; webinar. 2.5 minutes for a script that &rsquo;just works&rsquo; is good enough for me.
 
@@ -86,3 +74,6 @@ The snippet below is from my performance widget. Token generation is not super f
   Turns: 32
 
  
+## Things don't always go to plan
+
+I am integrating the Microprints library that I open sourced earlier - to keep an eye on changes. My local model seems to have trouble getting the correct files to render. I fixed most of the CSS issues (Claude Opus 4.6 struggled with that as well). I am still learning about how to make Phoenix Liveview applications modular, some of that can be done by reading, other learning happens the hard way.