11 posts tagged with "Engineering"

A useful coding agent needs more than good answers. Something has to call the model, expose tools, retain task state, and make the resulting work reviewable. That surrounding machinery is the harness.

CodeAF is an early-preview harness worth a bounded experiment, not a migration. Do its task handoff and checking loop help with your work? Start with one disposable repository and an unambitious request. This is early triage, not an endorsement or an Aliz adoption recommendation.

I don't know how many people I've told what my approach to AI and the whole industry was (and still kinda is). In short: with over 25 years in IT, having grown up on the C64 and Debian Potato, and loving coding, I really hated it. I still hate some parts. Not just because I thought it takes away the part of my job I love (or thought I loved), but also because the industry is at its lowest point right now in a lot of ways. And if that's not enough, it's all (mainly) driven by FAKE money and business. Yes, I like some conspiracy theories.

This post is about how and why I've recently taken a bit of a different direction: why I now use Omarchy at home, an agentic OS created by DHH, a deeply polarizing figure who praises AI like a god, and why I trusted AI agents to migrate my Java simulation game to C# and have been developing heavily with agents ever since.

Ask an agent how Aliz approaches infrastructure reviews, and a well-written Markdown page is a good starting point. Ask which repositories had the most indexed agent sessions updated this week, and the problem changes. Now you need consistent records, a time window, and a count, not another document explaining the conventions.

SQLite can help with that second question. But putting information in a database does not automatically make an agent smarter, safer, or cheaper to run. Someone still has to expose the right capabilities and teach the agent how to interpret the results.

The useful distinction is not "Markdown versus databases." It is knowledge versus records, tools versus skills, and retrieval versus evidence. The Dev Hub can remain human-readable while structured workloads get a better interface.

This is a small update regarding the AI Telemetry. The telemetry rollout was a long process due to resourcing issues and the rapid change of the harness APIs. It provided us a good amount of data, but every now and then it was questioned by people whether it showed the real data.

As we do not have that many people on the bench right now, I decided to spend some time on it, check what we have, what we don't have, and what needs to be fixed.

20 PRs, including 70 commits, were merged in after 2.5 days of vibe coding.

OpenTelemetry usage data · July–September 2026 · first quarterly review

AI activity at Aliz is substantial, and September brought a clear jump in agentic workflow activity. But the strongest workflows still have limited recorded reach, while cost and usage are concentrated among a relatively small set of aliases.

The next phase of AI Transformation should not be “use more AI.” It should spread the practices that already work, strengthen quality loops, and connect AI activity to delivery outcomes.

Internal survey · engineering AI adoption · wave 1 vs wave 2

Two identical-sized samples, four months apart. 42 responses in March 2026, 42 in July 2026. Every question in both questionnaires is charted below. Wave 2 added five questions and several new answer options; those are marked in green and have no baseline.

How to read the charts: grey bars = March 2026 · dark‑green bars = July 2026 · bright‑green bars = answer options new in wave 2.

I work in pre-sales, which means my job is to take a client's problem and turn it into something concrete enough that they can decide to work with us. Over the last few months AI has changed how I do this quite a lot, and I wanted to write down what actually made a difference, using two projects as examples: One Hungary and VEON.

The short version is that AI made me faster, but the more interesting part is that it changed which parts of the job are actually worth the time. I will try to explain what I mean.

I shipped a production application in TypeScript — a language I've barely used — with a Node/Fastify backend, a React frontend, Firestore for data, and Terraform-managed infrastructure on GCP. I worked mostly from a terminal rather than a full IDE, and the frontend was something I'd essentially never done. On paper that should have produced confident nonsense. It didn't, and the reason wasn't talent or luck. It was the workflow.

For a few weeks I worked strictly spec-first, and the loop had a fixed shape:

Plan → Propose → Codex review → Apply → Review → Archive

I planned and discussed the change; OpenSpec turned that into the artifacts (proposal, design, spec, task list), so my real work was the thinking and the option-weighing, not the boilerplate; an adversarial reviewer (Codex) tore into the proposal; I implemented it behind failing tests; the implementation got reviewed again; and finally the change was archived and its spec folded into the living docs. A lot of the code itself was written by an AI agent, which makes the guardrails the whole story.

Because the app was greenfield, the big-picture plan — the milestones — was drawn up front, before any change. I worked through them in order; then, as the system took shape and the real decisions started surfacing, I spun up OpenSpec changes on the fly, one per decision. So planning was two-layered: a stable milestone map set at the start, and a stream of small specs filling it in as I learned what the thing actually needed.

Here's the honest version — what genuinely helped, and what was ceremony I had to decide was worth it.

The Solution Block Hub only pays off if people actually reach for it — before they rebuild something we already have, and after they build something worth sharing. The problem is that "go search the Hub" is a context switch, and context switches don't happen mid-flow.

So now the Hub comes to you. Two skills put it directly inside your coding assistant, working across Claude Code, Codex CLI, and GitHub Copilot CLI: sb-hub-search (before you build — "do we already have a block for this?") and sb-hub-contribute (after you build — "is any of this worth turning into a block?"). Together they close the loop: reuse first, contribute back.

We build a lot of things at Aliz. Terraform modules, data pipelines, GenAI agents, app templates — hundreds of repositories across the organization. The problem is that nobody can find any of it. Someone on the Data track builds a BigQuery CDC pipeline, and six months later someone on AppDev builds the same thing from scratch because they didn't know the first one existed.

The Solution Block Hub fixes this. It's an AI-powered platform that automatically discovers, summarizes, and indexes our GitHub repositories — and puts a Gemini-based search assistant in front of the whole thing.