{"slug": "constraint-engineering", "title": "Constraint Engineering", "summary": "A developer built a decision-log feature for their productivity app Kombine in a few hours by feeding a YouTube transcript into Claude, which designed the UI against an existing design system and generated deliberately brief tickets for the mobile, web, and API repos. The developer credits the speed to project scaffolding around the LLM — reusable UI components, existing tests, CI checks, and project docs — rather than to the model alone, and notes the approach has shifted from detailed LLM-generated implementation recipes to short goal-and-notes tickets.", "body_md": "In March, I needed a swarm of agents to ship a feature. This time, I needed a coffee.\n\nI like thinking on paper. I enjoy my German fountain pen marking the surface of my Japanese notebook. It forces me to slow down and think before I write; changing ink soaked into paper isn't an option. Paper gives flexibility; an empty page can be anything, organized in a million ways. There are very few constraints.\n\nBut for anything I want to find again, I use digital tools, and those are opinionated, structured, and full of constraints.\n\nUsing decades-old software engineering principles, I built a new feature in my app in just a few hours, inspired by a YouTube video. I set constraints so I could let the LLM run loose and focus on the product.\n\nRecently I saw a [video of a Bullet Journal creator](https://youtu.be/dInecdJIKog?si=-bWJ4OxMKE2guVnP), showing a decision log. It reminds me a lot of the ADRs (Architecture Decision Records) I often use in the software I build. It has a structure, like:\n\nThe assumption is that you always make the best decision at the moment, with what you know at the time. It may not be objectively the best one; you will learn new information later, but the point is to record the state of the world when you make the decision. The reflection part comes later.\n\nIn the video, it's done on paper—5 sections in total, with some mid-section prompts to guide you.\n\nI saw the video right after it was published, and I had only one thought: how hard would it be to include this as a feature in my productivity app? It is a rather simple static form, with a few questions and answers. A new DB table and reused existing UI components. I had no idea yet how it should look and feel, but this is what I'd use an LLM for: to help me figure it out.\n\nIn case my non-existent marketing didn't reach you, I am building an app called [Kombine](https://kombine.dev/). It started as a Pomodoro timer with nice sync between all your devices, including your smartwatch, but has gained some fat in the last few months.\n\nSo I used the video transcript as input for Claude to work out how it could fit into my app. After an hour or so of a ping-pong match with prompts and responses, I had something. Something fitting nicely next to existing features.\n\nDesign was pretty fast; Claude Design just used my already established, aligned design system on all platforms: phone, tablet, and web.\n\nThen it created concrete tickets for mobile, web app, and API repos. The tickets were brief and vague on purpose. My approach has also shifted over the past year: from comprehensive recipes generated by an LLM for another LLM to implement, to a brief set of goals and notes—no code examples, rarely even a file name. LLM can figure things out quite well, follow observed patterns, go through project docs (because you have project docs, right?), and doesn't require babysitting.\n\n1 coffee later, I was testing it on the web app, and the mobile part was being built. It worked as expected, looked good, and even surprised me with a few nice UI touches I didn't explicitly plan during grooming.\n\nWhy was it possible so fast?\n\nIt's not just LLMs. It's everything I build (with LLMs) around the project.\n\nUI design was fast because Claude could use existing screens as references, pick typography and colors from the catalog, and reuse existing UI elements.\n\nThe implementation barely touched existing parts, so there was little risk of breaking anything. It also reused existing patterns and elements. There could be some duplication; Claude likes to do it, but it's not my concern now. I will run some static code analysis or Claude at some point for mechanical refactoring. Code is affordable to write and remove now.\n\nAll of this on top of existing tests, smoke runs, CI checks, etc. All the good practices that work with human teams.\n\nIn just a few hours of work interrupted with diaper changes and feeding time, I went from inspiration to a working feature. And I didn't need a swarm of agents or a software factory for it. TBH I'm not even sure if I like the idea of building a thing to build a thing.\n\nWhat blew my mind is remembering how much I had to build [back in March](https://swiderski.tech/2026-03-25-toilet-to-prod-pipeline/) to get a similar result. I had an orchestrator agent, planning agent, coder agent, QA, reviewer, etc. Their context windows and capabilities were so limited at the time that I had to divide responsibilities between them. This still works now, and is probably still useful for big projects. But I don't need that anymore.\n\nI use some grooming skills to question myself by checking existing docs and code, then planning GH issues and design.\n\nThis feature was a single ticket in mobile and 2 in the API/webapp repo. I used another skill I wrote to implement it end-to-end: create a branch, write code, run linters and tests, compile before creating a PR, then let CI do its job, and merge manually after skimming the code.\n\nI did not read all 5k lines of new code. I didn't need to: it was purely additive, CI confirmed existing behavior didn't change, and the blast radius was one new screen. The worst case was the new feature not working properly—I can live with that.\n\nReview decisions, not keystrokes.\n\nI want to be involved in every step, from product-level feature planning through design to reviewing the implementation plan. E.g., I changed the DB schema; I didn't like the idea of having 20 separate columns for answers, and went with JSONB since that data will always change as a whole and never be queried by field anyway.\n\nI want to be involved where it matters, not verify typos in code - I have CI for this. With constraints like a design system and an already established app with navigation, screens, UI components, event handlers, etc., there is little to do wrong—very little room to do anything other than the obvious implementation.\n\nI wanted to test it manually anyway. My goal was to verify how a paper-based decision log framework could be adopted into a digital environment. Building it took less time than a clickable mockup used to.\n\nThe same engineering practices that make human-written code better work well with LLMs. However, you need an engineer to build the workflow—a good one. Knowing frameworks or programming languages matters less than understanding engineering principles: knowing what NOT to do, when to look closely, and when to let go.\n\nWhat worked for this build:\n\nNone of this is LLM-specific. It's just engineering.\n\nI noted changing the Claude Code DB design on paper, though.", "url": "https://wpnews.pro/news/constraint-engineering", "canonical_source": "https://dev.to/asvid/constraint-engineering-41c1", "published_at": "2026-11-11 09:45:30+00:00", "updated_at": "2026-11-11 09:51:58.274547+00:00", "lang": "en", "topics": ["ai-tools", "large-language-models", "ai-agents", "developer-tools"], "entities": ["Kombine", "Claude", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/constraint-engineering", "markdown": "https://wpnews.pro/news/constraint-engineering.md", "text": "https://wpnews.pro/news/constraint-engineering.txt", "jsonld": "https://wpnews.pro/news/constraint-engineering.jsonld"}}