#ai-agents

Software project estimation usually asks a practical question: how much work remains before a defined completion state is reached? Agentic workflows can improve the answer by making estimation assumptions explicit, attaching size estimates to trackable work units, projecting those estimates into calendar dates, and feeding delivery outcomes back into future estimation guidance. The central opportunity is not that agents can guess better than people. It is that agents can help make estimation more repeatable, inspectable, reviewable, and correctable in large organizations with complex requirements, legacy systems, and cross-team dependencies.

An agent loop is usually described as a practical control pattern: execute, observe, validate, revise, repeat. That framing is useful for building systems, but it hides a more basic question. If one agent loop can inspect and steer another agent loop, and another loop can inspect and steer that steering loop, do we get a genuine hierarchy of problem-solving power?

Large repositories need continuous semantic maintenance. A practical inconsistency resolver would treat a Git monorepo as a versioned knowledge base, use deterministic checks where possible, spend bounded agentic and formal-reasoning budget on high-value candidate artifact groups, and open reviewable pull requests that repair drift across code, tests, documentation, schemas, configuration, and mirrored external systems.

This is a work-in-progress side-project setup for me, at most 4 worker hosts, 1 public box, and 1 monorepo. The aim is to maximize AI subscription usage and hardware usage while minimizing my oversight.

I finally set aside some time to experiment with agent orchestrators. It turns out that building one tuned to your workflow is straightforward. The agent drafts its own orchestration skill, you run it, flag what falls short, and it iterates. The result fits your repositories, build system, and other constraints including budget. You may start from scratch or fork an existing orchestrator.

I've used coding agents extensively at work, but until recently I hadn't tried building anything usable from scratch with them outside work. Opus 4.6 and GPT-5.3-Codex have both been impressive, so I thought I'd see how they perform on greenfield projects. At work, code reviews are mandatory. Personal experiments have leaner quality standards.

This post covers the deployment setup and three vibe-coded apps:

• A GitHub Actions workflow for server initialization and application deployment to the cheapest Hetzner cloud instance.
• An attempt to turn my earlier post on AI-assisted software requirements engineering into an application.
• A web app for tracking my boys' virtual piggy bank — weekly allowances and errand rewards.
• A voice-chat web application and task runner for sharing the vibe-coding setup with non-technical family members.

Rapid prototyping is effective for requirements discovery and alignment, allowing stakeholders with complementary expertise to explore how an aspect of a new product or an improvement to an existing one works in practice. Prototypes can also serve as partial reference implementations, encoding a meaningful subset of requirements in an unambiguous way.

Tracking software requirements and communicating effectively with all stakeholders when information is scattered across multiple systems like Slack, Google Docs, JIRA, Confluence, GitHub, and elsewhere can be challenging. While I wait for the industry to solve this, I experiment with makeshift solutions. My current workflow uses Cursor as the central hub. It operates on a requirements-focused GitHub repository that consolidates the relevant software-focused repos as submodules, copies of Slack threads, and Google Docs. I then use MCP to sync the remaining information.

AI models increasingly cover the how of building software products, reshaping the role of software engineers. The ongoing shift may simply result in yet another abstraction layer while still requiring a “software engineer” to guide the implementation. Alternatively, the responsibilities of product managers and software engineers could gradually converge. In the latter case, a deep understanding of technology is still relevant, but most of the remaining work consists of understanding where software can add value and capturing the requirements with sufficient clarity and detail so that the AI models can derive the implementation from them.

I migrated this website from self-hosted Ghost to GitHub Pages using Claude Code Pro. The process took a few hours.

Answering questions on how a product with many software components should work can be challenging. The software may have been written by countless developers over a long period of time, and many may no longer be available for consultation. In principle, maintaining a formal and complete specification separate from the implementation would help in understanding the product’s intended behavior. In practice, such rigor requires an engineering budget and expertise that may be available only when developing safety- or security-critical systems. Additionally, studying a formal specification for a complex system to verify if the implementation conforms to it or to propose a modification can be time-consuming and error-prone.

For less critical systems, partially specified and incremental specifications that remain unmaintained may currently be a cost-effective way to develop software in large organizations. Regression test suites, both manual and automated, serve as the de facto specification for correct behavior.

Used judiciously, large language models could play a part in accelerating product development velocity while keeping unwanted undefined behavior at bay. This article briefly covers some situations where product development might benefit from a lightweight AI-assisted requirements engineering process and speculates on how some aspects of the tooling could be implemented.