{"id":576,"date":"2025-08-18T10:15:11","date_gmt":"2025-08-18T10:15:11","guid":{"rendered":"https:\/\/yer.ac\/blog\/?p=576"},"modified":"2025-08-18T10:50:55","modified_gmt":"2025-08-18T10:50:55","slug":"vibing-in-kiro-to-create-a-self-serve-portainer-wrapper","status":"publish","type":"post","link":"https:\/\/yer.ac\/blog\/2025\/08\/18\/vibing-in-kiro-to-create-a-self-serve-portainer-wrapper\/","title":{"rendered":"Vibing in Kiro to create a self-serve Portainer wrapper."},"content":{"rendered":"\n

I recently (finally) got my invite to Kiro<\/a>, Amazon\u2019s new agentic IDE. I\u2019d tinkered with it, but never had a real use case outside of the usual \u201cmake me a to-do app\u201d test.<\/p>\n\n\n\n

Then Friday afternoon rolled around. With 30 minutes to go, I was asked to start parts of our Docker infrastructure. It\u2019s a simple click in Portainer, which got me thinking\u2026 we should automate this<\/em>. Developers can sign in and toggle services on or off, but that still blocks non-technical users from self-serving. Why isn\u2019t there a simple <\/em>dashboard for stopping (scale to zero), starting (scale to 1), or restarting a Portainer service? At least, not one that doesn\u2019t require infra changes or digging through old repos – and again, this is Friday afternoon.<\/p>\n\n\n\n

As an aside, our internal environments have a 1:1 mapping between service and container, so service-level actions are the quickest path. Your mileage may vary. This post is also more \u201cmental notes\u201d than tutorial.<\/p>\n\n\n\n

I wrote this before the recent Kiro announcement, see the final concluding thoughts. <\/p>\n\n\n\n

Validating with PowerShell first<\/h2>\n\n\n\n

First I wanted to confirm that Portainer exposes an API I could hit to scale services. If that worked, I could feed it into Kiro later.I used ChatGPT to outline the Portainer API boundaries, then had it generate a small PowerShell harness to prove the calls and auth. Straightforward enough: API key (Portainer \u2192 Account \u2192 Keys), your Environment ID, and a service name.<\/p>\n\n\n\n

The gist is:<\/p>\n\n\n\n

    \n
  1. Find the service by name<\/li>\n\n\n\n
  2. Pull its spec\/version<\/li>\n\n\n\n
  3. Change the replica count (0 = stop, 1 = start)<\/li>\n\n\n\n
  4. Update the service<\/li>\n\n\n\n
  5. Verify<\/li>\n<\/ol>\n\n\n\n

    With that working \u2014 and being able to scale to 0 or 1 easily \u2014 I dusted off my Kiro preview access.<\/p>\n\n\n\n

    Code below for reference:<\/p>\n\n\n\n

    $BASE    = 'http:\/\/portainer:9000\/api'\n$HEADERS = @{ 'X-API-Key' = 'your-key' }\n$envId   = 8    # change this to the environment id\n$svcName = 'PRODUCT-SIT' # change this to the service name under the environment\n\n# 1) Find the service by name\n$filters = @{ name = @{ $svcName = $true } } | ConvertTo-Json -Compress\n$enc     = [uri]::EscapeDataString($filters)\n$svcList = Invoke-RestMethod -Headers $HEADERS -Uri \"$BASE\/endpoints\/$envId\/docker\/services?filters=$enc\"\n\nif (-not $svcList) { throw \"Service '$svcName' not found on endpoint $envId.\" }\n$svcId = $svcList[0].ID\n\n# 2) Get full spec and version\n$svc = Invoke-RestMethod -Headers $HEADERS -Uri \"$BASE\/endpoints\/$envId\/docker\/services\/$svcId\"\n\n# 3) Set replicas to 0 (replicated mode only)\n\nif ($svc.Spec.Mode.Replicated -eq $null) { throw \"Service is not replicated.\" }\nWrite-Host $svc\n$svc.Spec.Mode.Replicated.Replicas = 0\n\n# 4) Update the service with the new spec\n$ver = $svc.Version.Index\n$body = $svc.Spec | ConvertTo-Json -Depth 100\n\nWrite-Host $body\n\nInvoke-RestMethod -Method Post -Headers $HEADERS -ContentType 'application\/json' `\n  -Uri \"$BASE\/endpoints\/$envId\/docker\/services\/$svcId\/update?version=$ver\" -Body $body\n\n# 5) Optional verify\n$verify = Invoke-RestMethod -Headers $HEADERS -Uri \"$BASE\/endpoints\/$envId\/docker\/services\/$svcId\"\n$verify.Spec.Mode.Replicated.Replicas<\/code><\/pre>\n\n\n\n
    Spec driven Vibe Coding with Kiro<\/h2>\n\n\n\n
    Kiro is another fork of VS Code with agentic AI built in, similar to Cursor. Where Kiro differs is its Spec Mode<\/strong>. We can write a compact prompt that defines data, actions, states, and constraints, and the agent treats it like a contract. For my prompt, I kept it rough. I just pasted my PowerShell as the API reference and wrote:<\/p>\n\n\n\n
    I can turn off\/on my docker instances by altering the scale set to 0 or 1 in portainer.\nI have a script to do this like this:\n{{ powershell code }}\nI would like system where I have a JSOn config file which holds the URL, APIKEY, and a list of service names.\nThen I want a UI for this which will:\n- Show all the services\n- Indicator to say if the svc is running or not (based on the scale >0)\n- An option to turn off (scale 0), turn on (scale 1), or restart (scale 0, wait, scale 1)<\/code><\/pre>\n\n\n\n
    First, Kiro will convert the prompt into system requirements. Each requirement will have its own Acceptance Criteria and will be written in a BDD syntax.<\/p>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n
    Once we are happy with the Requirements and validated its what we want, we can move to Design<\/strong> Phase. The design phase validates the technology choices it will use for the frontend and backend, designs and maps out the interactions between components with some sample code, and finally it adds details on testing strategy which it will use to validate itself as it goes. Here we can make any amendments (I didn’t) before moving on. Interestingly, over every test I did it defaulted to Node\/React\/Typescript in every instance.<\/p>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n
    The final phase is the Task List <\/strong>and is where we can see all the steps the agent will execute to be able to achieve the end-goal.  Each step has sub-tasks and a link back to the requirement for self-validation and guidance.<\/p>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n
    Whilst the screenshot above shows me post-execution, its simply a case of selecting “Start Task” next to an uncompleted item to kick the process off<\/p>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n
    Kiro also supports steering rules<\/strong> for guardrails and native MCP<\/strong> integration to plug in tools, APIs, and docs (Although I didn’t make use of this). <\/p>\n\n\n\n
    Let the magic happen…<\/h2>\n\n\n\n
    I kicked things off by running the tasks in order \u2014 starting with the basic scaffolding and React setup. As it progressed, Kiro validated its own work with unit tests and checks along the way.<\/p>\n\n\n\n
    Like most agentic IDEs, Kiro can\u2019t run commands without approval. Whenever it needed to spin up a server, run tests, or interact with the system, it prompted me first. You can add commands to a trust list, either as one-offs or using wildcards \u2014 for example, trusting all npm *<\/code> commands versus just npm start<\/code>. That means over time it can run more autonomously on repeat runs.<\/p>\n\n\n\n
    There were a few hiccups though. A common one was getting stuck on steps like \u201cValidating that Express server starts,\u201d since it doesn\u2019t seem to realise the terminal is tied up if the command keeps running. Similarly, Jest sometimes hung after running tests, waiting for me to manually stop it -which left Kiro stuck as well.<\/p>\n\n\n\n
    When I intervened (Ctrl+C to the rescue), it usually recovered and checked the terminal output to confirm whether tests had passed. But a couple of times it jumped to the wrong conclusion and marked everything as fine despite failures – I assume because there was no proper exit code or error thrown.<\/p>\n\n\n\n
    In those moments, the chat window proved useful. For example, when it couldn\u2019t confirm if the server was running (because the terminal was still tied up with npm start<\/code>), I told it to try curl<\/code> instead. It did, and even remembered that approach for later runs.<\/p>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n
    Interestingly, when I asked “Are you stuck?<\/em>“, the agent responded quite sarcastically telling me “I’m not stuck thank you, I am just busy!!<\/em>“.<\/p>\n\n\n\n
    The end result<\/h2>\n\n\n\n
    The end result was quite impressive really given my very basic<\/em> prompt. I updated my config with a few of our environments and ran the start command. This is way closer to a working system than I got from other agents.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    It was 99% the way there, the only thing that didn’t work well was the restart which was simply sending a malformed model to the API resulting in a HTTP 400. I simply switched to Kiro chat and told it there was a problem in a specific file and gave it the API info again and it corrected itself. I don’t know if I can blame Kiro for that though as I was hesitate to give it my real API key for testing until the very end in a human controlled test – I didn’t want it going rogue and messing up our environments!<\/p>\n\n\n\n
    Final thoughts on the output<\/h2>\n\n\n\n
    I mean, it did what I asked. In under half an hour on a Friday, with nothing more from me than a rough couple hundred characters and the occasional tap on \u201cTrust command,\u201d it built a system that actually worked and would be enough for my team to self-service our test environments.<\/p>\n\n\n\n
    Would I rely on this for anything beyond quick POCs? Probably not. It\u2019s a fun tool\/toy, and for an internal use case like this it got about 80% of the way there with almost zero effort from me. But if this were destined for production, I\u2019d need to review every file to be confident, and that\u2019s where I think these agents shine more as \u201cpeer coders\u201d than full replacements (For example I quite like Co-Pilot).<\/p>\n\n\n\n
    There\u2019s also the risk of people shipping AI-generated slop without understanding it. Honestly, if I\u2019d been a younger dev, I might have looked at this output and thought it was ready to ship even though I wouldn\u2019t have had the React experience (I still don’t!) to properly validate it.<\/p>\n\n\n\n
    More importantly, Kiro’s priced themselves out.<\/h2>\n\n\n\n
    I got very lucky<\/em> with my timing here as literally that evening<\/strong> Kiro officially announced the tiering and free-usage limits<\/a>, as well as the pricing plans.<\/a>  It looks like free users don’t get any spec requests at all (other than the 100 trial ones that expire), and even the $20 tier gets a mere 125 Spec requests and 225 Vibe requests. Even users on $40 pro accounts were finding that they were burning through their limits within an hour.<\/p>\n\n\n\n
    The issue here is that this doesn’t equate to 125 Spec requests or 225 additional interactions through vibing, as:<\/p>\n\n\n\n