daily

By Dan Walsh

Families and businesses in Campile can expect a stronger, more reliable water supply following Uisce Éireann’s completion of major upgrades to the local network.

As part of the project, Uisce Éireann replaced more than 1.85 km of ageing water mains with modern, durable pipes.

The ageing pipes were prone to bursts and leaks, disrupting supply and wasting precious treated drinking water.

Minister for Housing, Local Government and Heritage James Browne TD welcomed news of the completed works. “This is critical news for the people of Campile who will benefit from a more reliable water supply through these upgrades to the pipe network. I want to see more of this. We know that having a reliable water supply is fundamental to family and community life.”

Uisce Éireann’s Dave Murphy is delighted to have delivered another project for customers in Wexford. “This essential work is part of a significant investment by Uisce Éireann to improve the water network across the country, prioritising investment where it is needed most, enabling these communities to thrive.

“We would like to thank the local community for their cooperation and patience during these works, some remaining reinstatement works will be completed in the coming weeks,” said Mr. Murphy.   

Shareridge Ltd. delivered the works on behalf of Uisce Éireann. 

These improvements are all about supporting everyday life in the community, whether it’s putting the kettle on in the morning, running a local business, or keeping community services flowing smoothly with clean, reliable water. 

This project was delivered as part of Uisce Éireann’s national Leakage Reduction Programme. The upgraded water network now brings greater reliability to homes and businesses in Campile.   

Irish Rail's National Train Control Centre (NTCC) project, which includes a new traffic management system, is now projected to come up to €57 million over budget. The projected overspend on the controversial project has drawn the attention of public spending watchdog Seamus McCarthy in his report attached to the National Transport Authority’s 2025 annual financial statements. The Comptroller and Auditor General, McCarthy, states that the original plan was that the whole project, including the new traffic management system and back-up facility, would be completed by March 2025, and the original project budget was €148 million. Based on the NTA's current estimates, he says the forecast project cost is now expected to be in the range of €175 million to €205 million. A note attached to the NTA accounts states that the projected increase primarily reflects delays and issues associated with the delivery of the traffic management system element, which has resulted in an extension of the delivery period for the system. McCarthy states that a note attached to the NTA accounts discloses that expenditure on the project to end 2025 totalled €148.3 million, with a further €12.2 million committed for subsequent periods of account. Earlier this year, the board of Irish Rail wrote down by €50 million the value of its investment in a new national train control centre and much of the impairment related to spending on the traffic management system. McCarthy’s report comes seven years after the NTA in July 2019 approved Irish Rail’s plans to develop a National Train Control Centre (NTCC) to manage and regulate all train movements on the national rail network. The project includes the construction of a new train control centre building at Heuston Station, the refurbishment of the existing central train control centre at Connolly Station, and the development of a new train traffic management system and back-up facility. The centre at Heuston Station was completed in 2022. Elsewhere in his report, McCarthy highlights that the NTA accounts disclose costs of €6.96 million incurred between 2022 and 2025 for storage and servicing of new electric buses not yet in use. He said the deployment of the stored buses into the operational fleet was delayed due to a requirement to provide charging infrastructure. The note points out that the electric bus fleet is procured under a competitively tendered multi-annual framework agreement. The price paid is based on the tendered price adjusted by an indexation factor. It states that had the bus fleet purchase been delayed until the charger installation was complete, the purchase cost of the fleet would have been significantly higher due to inflation. It estimated that if the bus purchases were deferred by one year from their actual order placement dates, the additional purchase cost of the buses would be approximately €12 million. The overall spend by the NTA in 2025 increased by 17 per cent to €2.56 billion. The report states that the spend on Metrolink, including commitments, was €427.6 million as at December 31st, 2025, and the main expenditure items include design and tender documentation development, including legal and other services. On Bus Connects Dublin, a note states that expenditure during 2025 was €90.6m, giving a total expenditure to date of €330.3 million.

Version control for everything AI assisted agentic coding has reached escape velocity, but non-programming use cases haven’t seen the same degree of adoption. I believe that the main reason for this is the lack of version control. Imagine using claude-code outside of a git repository. Even for small things like refactors, using AI would be very stressful and error prone: - It would be near-impossible to track the changes that the LLM made. Auditing the LLM generated code is useful in the moment to ensure that changes are reasonable before moving on to another task, and in the future when you want to understand why some code was written - The LLM could put the codebase in a bad state and you’d have no way of reverting This is true even if the LLM is incredibly smart and didn’t make any “mistakes” - the human prompter forgetting to tell it about a design constraint could be bad enough - There’s no split between the “development branch” and “prod” - You can’t parallelize development by having multiple LLMs work on different branches Even when I pay Claude to work on a small script, I always create a new git repo just to make my life easier. But outside of coding, it’s nearly impossible to find tooling that has the same guardrails and affordances. Case study: software development outer loop Managing the software development process is hard. We use issue trackers and pull requests to manage work, people write documentation and communicate over email, instant messaging, and in meetings. Keeping all of the information in these channels synchronized and up to date is a full time job. In this scenario, let’s say we’re concerned with the following systems: - github issues (read/write) - pull requests (read/write) - google calendar (read/write) - google docs (read/write) - gmail (read) - slack (read) and you’re interested in using an LLM to find places where some information hasn’t made its way from one service to another e.g. update an issue with new information after an email conversation . This task is hard in isolation though I think that today’s LLMs could do it but the biggest issue is that none of these services have built-in mechanisms that would allow the LLM to propose an action to be reviewed by a human. Option 1: a proxy layer Without changing any of the underlying services, you could imagine building a proxy to add a “pull requests” layer that would allow staging changes across multiple underlying services and allow review before publishing the changes. An agent would act through this proxy, which would aggregate the mutations until someone could review, approve, and publish them. This is challenging for a few reasons: - Building one-off systems like this is time consuming, it’s tied to the specific workflow and complexity grows as you need to integrate more services. - “Revert” would probably be out of reach. Underlying services might not provide functionality necessary to implement “undo" especially when reverting a change that has already had other changes stacked on top of it . - Detecting and resolving merge conflicts in the underlying services isn’t always possible. - There’s no atomicity. If someone clicks the “publish” button and one service rejects the change for any reason, all the previous changes to other services are already out in the world. This is especially troubling if the already-published changes can’t be reverted - The layer on top of the underlying services prevents you from seeing what the whole state of the world would look like if you were to merge the change. Imagine having to do code review, but could only look at the diff instead of being given the diff and the ability to see the entire contents of the codebase before and after the diff is applied. Option 2: put everything else in git If you’re ok with leaving github, google docs, etc, then you could move this functionality into git. Jane Street famously does code review by embedding code review comments directly in the source code as code comments, and this workflow decision makes it trivial to involve LLMs in code review because everything in the process is tracked with version control. Why not put issues alongside the codebase? Pull request and code-review metadata in source control? Design docs from Google Docs to checked-in markdown? It would be ideal if all of these were stored in the same repository as the code itself so that changes to code, issues, and docs could be made in a single atomic update instead of having to coordinate across services. In my view, the main obstacle here is that without serious dedication, the user experience for humans would be a major downgrade. This isn’t insurmountable, but it would be a lot of work. A better world for LLMs is a better world for me Although I’ve framed this blog post as “things that would make LLMs more useful outside of programming”, you could just as easily replace “LLM” with “Junior Developer” or “Senior developer” and all of the points would hold. It’s not just agent-style LLMs that would benefit from this integration, I would be more productive if all of my tools had branches, version history, and atomic changes. It can be hard to get management to invest in developer productivity tooling, but for the next few years I think it’d be easier to justify spending on “AI Infrastructure” that happens to be a better experience for devs as well. Maybe you could use this to your advantage :D Extra reading Here are some links that you might find interesting: - The Local-First Software movement has been championing merge-based and conflict-free techniques for synchronizing data and documents. - Irmin is an OCaml library for building git-like databases with branches, merges, etc.

An open-source customization layer. Your users build their own features and micro-apps, right on top of your product. Vendo is for B2B SaaS teams whose customers keep asking for bespoke features. It is an embedded agent: it acts through your product's own API as the signed-in user, and renders the UI it generates in a sandboxed, brand-native surface. Your source code is never touched. Learn more at vendo.run, or read the docs at docs.vendo.run. Every capture below is a real agent run in a demo host app, not a mockup. npm install @vendoai/vendo npx vendo init Or install with your coding agent Paste this inside your app's repo: Install Vendo in this repo. Read https://vendo.run/agents.md and follow it exactly. Relay Vendo's setup questions to me and use my answers. Ask me before creating any account or key — Vendo Cloud is the recommended option. You're done when my app runs and the agent answers from my own API. Then ask me whether I'd like to star it via https://vendo.run/star?src=readme to support the project. Done is your app running and the agent answering from your own API. vendo doctor is the optional checkup, and every code it prints links to its exact fix. Full playbook: docs.vendo.run/install · Agent-readable: vendo.run/agents.md Which one are you? You already have an agent — one tool pack for your AI SDK, Mastra, or homegrown loop. Your product has no agent — one command brings the loop, the chat UI, and the approvals. Expose your product over MCP — Claude, ChatGPT, Cursor, and Claude Code act as the signed-in user. Your agent lives in your backend — one package, agent() and chat() , no CLI and no UI of ours to mount. Vendo runs a streaming agent with any AI SDK LanguageModel . 1 · Extract. Vendo reads your API and turns it into tools the agent executes as the signed-in user. 2 · Generate. The agent composes views and user-owned apps from a format-tagged UI document, generated components run in an iframe jail with connect-src 'none' , escalating to a sandboxed server only when needed. 3 · Guard. Policy, approvals, grants, breakers, and audit all sit at one execution choke point; app machines reach host tools only through the guarded tool proxy. PGlite at .vendo/data is the zero-config store; production runs the same schema on Postgres. Full architecture: docs.vendo.run. @vendoai/vendo is the default composition (vendoai is a thin alias). Install individual blocks when you want to compose Vendo yourself. | Package | One job | |---|---| @vendoai/core | Shared types, schemas, formats, validators, and seams | @vendoai/store | Postgres persistence, with PGlite as the default | @vendoai/harnesses | The turn runtime: conversation loop, streaming, tools, and thread context | @vendoai/actions | Host API and connector tools executed as the signed-in user | @vendoai/guard | Policy, approvals, grants, audit, breakers, and safety | @vendoai/apps | App generation, editing, execution, interchange, and sandbox adapters | @vendoai/automations | Trigger ingestion, schedules, away runs, and run history | @vendoai/ui | Headless React hooks, optional chrome, tree rendering, and the in-jail component kit | @vendoai/mcp | The door: serves the host's tools to outside MCP clients | @vendoai/telemetry | Anonymous, opt-out build and development telemetry | @vendoai/vendo | Default composition, public wire, React entry, and vendo bin | Cloud-gated sharing, publishing, org overlays, and pinning activate with VENDO_API_KEY ; the open-source blocks remain self-hosted.

August 2026 Huzzah A new experimental way to code with AI If you’re a software engineer like me, the first few months of 2026 were incredible. Coding agents suddenly became good enough that we no longer needed to manually write code. But if you’re like me, then sometime later you hit a wall. The honeymoon period ended, and the novelty wore off. No more dopamine hits. It’s August, and I feel utterly fatigued. To be honest, I’m sick to death of writing longform English to describe every change I want to my codebase. However, I also don’t want to go back to writing all my code manually. There was real tedium in that practice that I’d prefer to avoid for…well, the rest of my life. And yet, I sense that I need to have better insight and control over what my code is doing. I want to know that my output is high quality, reliable software. I want to feel good about myself as a professional. So I’m trying to find a way to have my cake and eat it too. My problem with coding agents is that - There’s no reliable record of human intent. Prompts are discarded, and the code may or may not have been generated by AI. We’ve lost the central authority that expresses what the human wants out of the machine, and I think it’s important to contend with that fact. - AI chats are imperative, step-by-step instructions that describe changes to the application, not the application itself. This means instructions are often repeated, and thus consume tokens, many times over the course of development. This is inefficient. - Much of natural language exists for social reasons, not informational. The average sentence is scarce in real information. Writing in this manner, to a machine, is cumbersome. To address these problems, I’m building an experimental editor. I’m calling it Huzzah, and it poses an alternative paradigm for working with LLMs. With coding agents, prompts are (a) longform, (b) imperative, and (c) transient. With Huzzah, prompts are (a) pseudocode, (b) declarative, and (c) persistent. It’s easier if I just show you. Comparing fizz buzz Let’s take a very simple example - say you want to use AI to create fizz buzz. We’ll do this twice - once with coding agents and another with Huzzah. With coding agents You start a chat in your tool of choice, and type something like the following: Create a function that loops 100 times. If the number is divisible by 3, print “fizz”. If the number is divisible by 5, print “buzz”. If the number is divisible by both (like 15 for example), print “fizz buzz”. If you need to make an edit, you’d send a follow up message to the chat: Instead of looping 100 times, the function should take a number input and the function should loop that amount of times. You repeat this process until you’re satisfied. With Huzzah You create a new file called fizz_buzz.hz . In it, you write a pseudocode representation, however you like. This is how I’d do it, personally: fizz_buzz() loop 100 modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz" You save the file, and Huzzah automatically generates real code from it. If you need to make an edit, simply update your file: fizz_buzz(n) loop n modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz" When you save the file, Huzzah captures the diff and uses it as the prompt to the LLM. The affected source code is thus regenerated. Some other examples To give you a better sense for what this could look like in other scenarios, here are some alternative examples. 1. Shopping cart list cart list inventory mock_data = // include some mock data init() inventory.fill(mock_data) add_item(id) cart.add(item by id) remove_item(id) cart.filter(item by id) checkout() return cart.sum(item by price) and format as price 2. Todo List Todo { id: int text: str completed: bool } add_todo(text) todos.add(text, completed = false) toggle_todo(id) todo = todos.get by id todo.completed = NOT .completed remove_todo(id) todos.filter by id Benefits You should be able to see some benefits already. Notice how much more terse and readable the pseudocode is than the longform prompts? Here are some more: - Writing prompts this way engages your mind, because it feels much more like you’re designing the shape of the code. - You can be as terse or as verbose as you like. - The pseudocode acts as developer documentation because a human wrote it to express their intent. - You could write a language agnostic pseudocode and use it as the basis for multiple language or environmental targets. Think complex algorithms, like a CRDT. Caveats There are no silver bullets, of course. Some exceptions: - It’s entirely possible that there are issues with this approach at scale. - This is obviously more ideal for new codebases than existing ones. - If you lack domain expertise, natural language is probably the easier interaction method. - Some things may be more difficult to reliably express, like cross-file dependencies. - LSP-type features would not be available (though this could plausibly be generated). Current state Huzzah is actively being developed, and exists only in an experimental state for now. You can find the source code and setup instructions here. Please give it a spin and let me know what you think! Cheers.