[{"content":"spec-lite is my take on a library for spec-driven development (SDD). I built it with a simple goal: make structured AI development lightweight, easy to use, and portable across coding agents. I usually have subscriptions to multiple AI coding tools, including GitHub Copilot, Codex, Claude, and Gemini. I wanted to carry my work from one tool to another without having to explain the project all over again.\nIt draws inspiration from existing SDD libraries such as spec-kit, with workflows shaped around the different ways developers work: starting a project, adding a feature, fixing a bug, reviewing code, or updating documentation.\nThe idea is straightforward. Capture what you want to build, turn it into a plan and verifiable tasks, and keep those decisions alongside the code. That gives the next agent, or the next developer, something concrete to pick up.\nHooks take that workflow further: they let you connect spec-lite to your own tools, services, and automation, making it a foundation you can keep extending as your development process evolves.\nFeatures Switch coding agents and keep your momentum This is the feature that motivated the project. Start planning in Claude Code, continue implementation in Codex, and review the result in Copilot. Plans, specifications, and reviews live in your repository, so each agent can read the same project state.\nspec-lite provides native integrations for Codex, Claude Code, GitHub Copilot, and Pi, generating the agent and skill formats each tool expects. For other tools, you can use generic Markdown prompts or export a portable prompt bundle. The continuity comes from the artifacts you save with the project.\nHooks: connect spec-lite to your entire development workflow Hooks are among spec-lite\u0026rsquo;s most powerful concepts. They open up integration possibilities wherever a command, script, or HTTP request can take you. Your team\u0026rsquo;s tools and processes can become part of the development workflow, with automation triggered when it matters most.\nThe model is simple: a role announces an event, such as implement.post or review.verdict, and subscribed hooks respond. Depending on the event, they receive context such as the feature, changed files, review verdict, and summary. That context lets an integration act on the work that just happened.\nBuild the integrations your team needs For example, you could configure hooks to:\nRun your team\u0026rsquo;s test suite, formatter, or custom policy checks after implementation. Send a review summary to Slack or Teams through a webhook or adapter. Update an issue tracker through its API when a feature reaches a milestone. Trigger a CI workflow or publish an artifact through a script or service API. Hand off to another skill or agent, or provide a custom prompt for the next step. These are examples of what you can build with hooks. You supply the commands, endpoints, or handoff instructions that fit your environment. The integration surface stays open as your toolchain grows.\nUseful built-ins from day one spec-lite ships with some built-in hooks.\nThe optional Git workflow hooks show how much a few integrations can accomplish together. They can give a piece of work its own worktree and branch, commit progress as tasks finish, push the completed work, and open or reuse its pull request.\nPull request support includes GitHub and Azure DevOps, plus a custom adapter option for other providers. You can build on that flow with your own checks and notifications.\nAutomate the checks and keep the decisions Gates and checkpoints let hooks shape what happens next. A gate can block progress on a failed check and send the agent back to fix the problem within a bounded number of attempts. A checkpoint pauses for your answer in chat or through a configured GitHub channel. Rules can select the next step automatically when conditions are met, with limits on automatic handoffs.\nFor example, you could require tests to pass, hand the result to Review, and ask for a decision before the pull request is opened. Pending decisions survive the session locally; an active agent carries out the next step when you return.\nThe CLI provides validation and dry-run previews so you can inspect the wiring before it runs.\nHooks are a powerful way to connect spec-lite to your existing development workflow. They let you automate checks, enforce conventions, build evals, and much more.\nUse the workflow your task needs A new application and a small bug fix deserve different amounts of ceremony. spec-lite\u0026rsquo;s agents and skills let you choose the right starting point.\nThe Brainstormer helps refine an idea, the Planner develops a technical blueprint for work spanning multiple features, and the Feature Planner scopes a single enhancement. The Architect handles system design. For a well-scoped autonomous build, there is also a YOLO agent that can take you from idea to implementation (if you feel like living dangerously).\nFocused skills cover implementation, debugging, testing, data modeling, DevOps, and more. Use a full workflow for a new project, or go straight to Fix and Review for fixes and enhancements to an existing project.\nKeep features traceable from plan to review Large requests become easier to reason about when you can follow each piece through delivery. Features have stable identifiers, such as FEAT-001, that carry through plans, specifications, implementation, tests, and reviews.\nFeature specifications break work into small, verifiable slices, giving implementation and testing a shared reference.\nGive your project a memory Repeating the same conventions in every conversation gets old quickly. Shared memory keeps standing instructions in .spec-lite/memory.md, where every role can read them.\nThat might include your API error format, testing conventions, architecture rules, or the requirement to store timestamps in UTC. Memory can be bootstrapped from evidence in the repository, and durable conventions can be captured automatically as work progresses, so you don\u0026rsquo;t have to remember to record them yourself.\nCommit that memory with your plans and specifications, and the next person or agent gets the context too.\nChallenge the plan, then review the implementation The Plan Critic pressure-tests feasibility, risk, quality, and adaptability before implementation begins. It gives you a chance to catch an expensive assumption while changing it is still cheap.\nOnce code exists, Review brings correctness, security, performance, testing, and dependency vulnerability checks into one report. Dependency checks use live GitHub Advisories by default and include remediation guidance.\nYou can review selected files, a feature, completed features in a plan, or dependencies alone. Feature reviews use the captured changeset to establish their scope. Findings include severity, evidence, and concrete fixes; unavailable checks are recorded as limitations. The report can then feed into Fix or Implement for follow-up work.\nspec-lite also maintains a TODO list of open items, so you can track and prioritize them. These items are captured during implementation or review when they are identified as outside the scope of the current work.\nKeep documentation moving with the code I wanted documentation to be part of delivery. You choose the output directory and level of detail: technical documentation covers the README and architecture, while the full set adds quickstart, usage, and individual feature guides.\nYou can generate the configured set, refresh one document, or update only the parts affected by a change. There is also an option for Implement and Fix to request documentation updates as development happens.\nThe writers work from verified code and preserve clearly human-authored content. The aim is documentation that explains the software you can actually run.\nStart with conventions for your stack spec-lite includes baselines for common technology stacks, including TypeScript, Python, Java, .NET, Go, and Rust. These give planning and implementation sensible ecosystem defaults, such as idiomatic patterns for the chosen language.\nYou can also keep project-specific helper scripts for your project\u0026rsquo;s needs. Think of Bash scripts, which agents are good at creating and using.\nInstall once and carry the workflow with you Reusable agents and skills can be installed globally, while each repository keeps its own settings and working state. That makes it easy to bring the same workflow to another project.\nThe update command refreshes configured providers, migrates older configuration and feature layouts, and preserves Project Context edits by default. Obsolete generated files are removed with confirmation.\nFor a chat tool or an unsupported coding environment, export combines selected roles and references into a self-contained Markdown prompt. You can take the workflow beyond the native integrations.\nGetting started The quickstart requires Node.js 22 or newer. Install the CLI and the roles for the coding tools you use:\nnpm install -g @abranjith/spec-lite spec-lite install --global --ai codex,claude-code,copilot,pi Then initialize your project:\ncd your-project spec-lite init Setup records your providers, project profile, and documentation preferences. From there, select a role in your coding tool and give it a task. For example, ask the Feature Planner to scope an enhancement, use Implement to build it, and use Review to assess the result. Commit the resulting plans, specifications, and project context alongside the code so the next session can pick up where you left off.\nWhat excites me most about spec-lite is being able to choose the tool that suits the work while keeping the project moving. The specifications, decisions, and progress stay with the code, and hooks connect that work to the rest of your development process. You can start small and build a workflow that grows with your project.\nFor complete documentation, visit the spec-lite repository. It is an open-source project, and contributions are welcome. If you try it, I would love to hear which workflows help you and where it could improve. You can report issues, suggest features, or submit pull requests on GitHub.\n","permalink":"https://abranjith.github.io/posts/ai/spec-lite-lib/","summary":"\u003cp\u003e\u003ca href=\"https://github.com/abranjith/spec-lite\"\u003espec-lite\u003c/a\u003e is my take on a library for spec-driven development (\u003ca href=\"https://github.github.com/spec-kit/concepts/sdd.html\"\u003eSDD\u003c/a\u003e). I built it with a simple goal: make structured AI development lightweight, easy to use, and portable across coding agents. I usually have subscriptions to multiple AI coding tools, including GitHub Copilot, Codex, Claude, and Gemini. I wanted to carry my work from one tool to another without having to explain the project all over again.\u003c/p\u003e\n\u003cp\u003eIt draws inspiration from existing SDD libraries such as \u003ca href=\"https://github.github.com/spec-kit/\"\u003espec-kit\u003c/a\u003e, with workflows shaped around the different ways developers work: starting a project, adding a feature, fixing a bug, reviewing code, or updating documentation.\u003c/p\u003e","title":"Spec-Driven Development with spec-lite"},{"content":"Artificial Intelligence (AI) is here and boy has it spread like a wildfire over the last few years. AI is not just in the software people use, it\u0026rsquo;s practically stapled to almost every tech headlines these days. I sometimes wonder how people separate actual substance/signal from the noise around AI. There is lot to unravel with AI, but as a software engineer I will keep this post around the impact AI has had in our field which has been quite remarkable. Needless to mention there is also a lot of noise which I will try to address as well.\nFirst things first, why is there so much discussion, so many AI coding tools, startups surround automating software engineering ? Well, there are many reasons and below are some of them,\nAs it turns out, a lot of modern software is a bunch of text (code) writeen by humans (well, at least until now). And Large Language Models (LLMs) have become really good at generating various forms of text including code. I am not saying software engineering is just about generating code (more on that later), but that\u0026rsquo;s a big part of it.\nSoftware Is Eating The World: World (Countries, Companies) is in need of enormous software in order to stay competent (and in many cases relevant). It’s no surprise that software companies are valued in the trillions—digital empires are booming, and there’s no slowdown in sight. Now imagine even if a small percentage of it can be taken over by AI. 1 2\nThe Journey So Far Code Completion I remember from early days of using ChatGPT to generate code and then using Github Copilot, it was quite an interesting phase. Of course the quality of code with the initial models were mediocre at best, as the models got better, the quality of code improved quite significantly. This was the initial wow moment and definetly felt like AI was indeed helping with writing code with a few lines of clear instructions provided in english. But that basically was all it could do, i.e. churn out code without a lot of context. This was still useful and removed some drudgery work from engineers. I have had a decent experience with auto code completion, although code generated by the copilot required thorough review and testing.\nEdit Mode I am using Edit mode for the lack of better term. But this was an advancement to just churning out code based on simple instructions. You could provide context (more on this later) to the LLM, so the code generated would understand the surrounding context and would generate more meaninful code. For e.g. let\u0026rsquo;s say I have some existing code and I want to generate unit tests for the same, or I want to generate documentation for existing code, or I want to generate code in a certain style based on the current repostory etc. This definetly felt like an improvement from just code completion and AI was already getting helpful in improving existing codebases along with generating new software. And also because now it had the context, it was helpful in understanding complex codebases where once could ask copilot to summarize, ask questions etc. Personally, I did use some of the features in production codebases to improve test coverage, documentation in addition generating code. Code quality felt better in this phase (as compared to previous), yet it still required scrutiny and proper test coverage. I used the code generation aspect in limited capacity, where I would give specific instructions with examples where possible and in some cases provide the definition of function in terms of parameters etc. vs asking the LLM to generate entire classes/ files. I got better results with my approach which also took some inspiration from Simon Willison\u0026rsquo;s blog.\nAgent Mode Enter the agent mode and this feels like a whole new beast. So far, we had only seen the code generation ability of the LLMs, and although definition of agent mode is different depending on who you ask, in general this felt like the next phase where LLMs could not only meaningfully generate/ explain code, but now could could use other tools/scripts to solve more complex tasks. For e.g., create/ scaffold new APIs, write \u0026amp; execute tests, find and fix issues, even generate complete application etc. Other important thing to note here is, not only the tools such as copilot, claude code are getting better in generating software, the underlying LLM models are also getting better in terms of quality of inference which is great! I will share more detailed thoughts based on my experience with new way of creating software with agentic AI.\nOverall Overall, I must say it\u0026rsquo;s been a great experience and even though there is a lot of hype \u0026amp; false promises surrounding this topic, it does feel like in general we are heading in the right direction when it comes to software engineering. Here are some thoughts,\nI do feel a lot more productive when it comes to using AI in software engineering. And that is based on my experience so far using these AI tools both professionaly and personally. I also think (if it hasn\u0026rsquo;t already), AI is going to transform the field of software engineering.\nI do feel a lot comfortable these days using AI to generate more of the code, generate unit tests, integration tests, write documentation etc. I do want to add that it\u0026rsquo;s very important that the content that is generated by AI is thorougly verified.\nI try to be methodical in using these tools for serious work. For e.g. when it comes to code generation, I provide releveant context, descriptive comments, documentation, in some cases blueprint (pseudo code), examples etc so I get better quality. One of the challenges here (specially with agents) is letting AI do too much work (modifying too many files or generate too much code) where it becomes too much for me to review and cleanup. That brings to my next point, that generated code still requires thorough review. At the core, it\u0026rsquo;s still the LLMs that is generating text. While LLMs are really good at generating semantically meaningful text, it\u0026rsquo;s still inferenced text based on data that it is trained on (which is largely internet data).\nI also try to use agents iteratively and not use features such as auto-save (or YOLO) for serious work and I have had satisfying results from this approach. Using agent to review what\u0026rsquo;s it written as a first pass, also specifically giving instructions (prompt) to follow certain rules, break down large tasks into phases etc. helps. For e.g. once I was working on a large file and asked agent to refactor something, it deleted a lot of code (which was scary!), so now I specifically give instruction to not delete code and so on.\nI will write a more in depth article about some of these topics, but two really important skills one\u0026rsquo;s got to develop with using these tools are prompt-engineering and context-engineering.\nOn YOLO mode - while YOLO mode is super fun, I think it\u0026rsquo;s best suited for fun/ toy projects. For e.g. building a full stack app with a bunch of features with basically a large instructions document and let agent go at it doing all kind of auto-save, delete files, run scripts etc. So deftinelty be careful while using this.\nI feel one\u0026rsquo;s got to learn a way to work with these tools and the techniques that work for me may not work for someone else.\nSoftware engineering becoming more accessible - I think this is a great win. Today if you have an idea, bringing that idea to life is much more achievable, thanks to AI and this just doesn\u0026rsquo;t apply to software. \u0026ldquo;Solopreneur\u0026rdquo; is already the trend word! Hoping to see some great ideas come to life, even solve real world problems.\nWhat Next Impact of AI in software engineering has been huge and what\u0026rsquo;s crazy is it still feels like we are just getting started. I may be biased, but I can\u0026rsquo;t think of any other field with such an impact or may be we software engineers are the early adopters to have embraced AI with both hands, not sure. No wonder companies (big \u0026amp; small techs alike) are spending so much time, money \u0026amp; energy into creating AI tools for software engineering. It\u0026rsquo;s been quite a journey so far, at times even overwhelming given how quickly things are changing. But, as with any technology trend, things will calm down, the dust will settle, and the outliers will quietly vanish.\nHere is what I think we are headed next,\nWorld will see a lot of software - I read somewhere that SaaS is mostly non-existent in some of the countries because it\u0026rsquo;s cheaper for companies to make their own software due to cheap labor than paying someone else. While I don\u0026rsquo;t think that will be largely true for rest of the world, there may be some use case where creating your own sofware instead of paying for one might be cost efficient for companies. For e.g. think of a chat application. Fairly easy to build (now with AI given how many chat applications there are), low risk. I am not saying all companies will now build their own software, but it may make sense economically for some.\nProprietary vs Open source software - I am a big fan of open source software. We were already seeing big tech companies promoting, supporting, cotributing to open source. I think the trend will get even stronger with AI in software engineering. We will likely see more open source software as it becomes cheaper creating software. And moreover it will benefit all parties involved (including AI agents!)\nProprietary LLM models - While there was and to some extent still is a lot of excitment around open source LLM models, I get a feeling, industry as a whole is moving towards proprietary LLM models. Not thrilled about this trend — feels like we\u0026rsquo;re handing all the cards to a few giants, and we know how that game is played. I hope I turn out to be wrong on this.\nProgramming Languages - Although not immediately, but as more \u0026amp; more software will be written by AI, I wonder if programming language features will be developed keeping AI as the primary user. Same applies for all the tooling surrounding software such as build tools, packaging tools, CI/CD pipelines\n","permalink":"https://abranjith.github.io/posts/ai/ai-thoughts/","summary":"\u003cp\u003eArtificial Intelligence (AI) is here and boy has it spread like a wildfire over the last few years. AI is not just in the software people use, it\u0026rsquo;s practically stapled to almost every tech headlines these days. I sometimes wonder how people separate actual substance/signal from the noise around AI. There is lot to unravel with AI, but as a software engineer I will keep this post around the impact AI has had in our field which has been quite remarkable. Needless to mention there is also a lot of noise which I will try to address as well.\u003c/p\u003e","title":"Thoughts on AI"}]