#dev

• Problem decomposition
• Clear communication & spec writing
• Core technical foundations: file systems, access control, networking, APIs, version control, data structures, databases, deployment
• Software development skills: Debugging, Testing, Refactoring, Design patterns, UI/UX
• Project management: requirements, prioritization, scoping, ...

• Delegation: context engineering agents for success; parallelizing.
• Verification: efficiently reviewing and testing code/output; setting stop-points.
• Expanding scope: instead of time saved as the metric.
• Education: teaching AI-based coding, debugging, reviewing/testing.
• Product management: combining requirements + UI design + architecture + engineering + deployment.
• Cross-discipline: blending code with design, governance, finance, marketing, ... ("computational creators").

const branch = await $`git branch --show-current`;
await $`dep deploy --branch=${branch}`;

• Use standards. Or, write your standards in README.md and tell AGENTS.md / CLAUDE.md to read it.
  • Use a standard file structure. Or in README.md, list what each file is for. Helps agents pick the right file for context.
  • Use a standard build/lint/test setup (e.g. package.json scripts). Or
• Localize context, i.e. add context in files that use them. E.g. add comments in test files on how to execute them.
• Keep files modular so agents can read less code and conserver context.
• Write a developer's guide.
  • Use with /init in Claude Code / Codex / ... or have an LLM generate a developer guide.
  • Edit manually. Agents don't write great specs.
  • Document the design.
  • Write DETAILED specs to reduce deviations.
• Share goal while specifying tasks. Helps agents fix related stuff.
• Use deep reasoning mode, e.g. "think harder" or "ultrathink" in Claude Code, or -c model_reasoning_effort=high in Codex.
• ⭐ Run parallel agents in different windows and share agent feedback with each other. E.g.
  • Server/API coding in one window. Client coding in another.
  • Plan/ask in one window. Execute in another.
• Add debug logs to help agents spot errors.
  • Start/stop of long/complex operations, state changes, external interfaces.
  • Include full objects in logs. Prioritize diffs. Trim long contents.
  • ⭐ Give access to debugger, e.g. Chrome remote debugging at localhost:9222
• Agents write poor tests. So:
  • Manually add important ones.
  • ⭐ When you find a bug, ask the agent why the tests missed it and have it add.
  • Review and remove useless ones.
• Ensure agent passes test cases. Tell them not to disable / skip failed tests.
• Have agents create a new branch per feature and auto-commit. Merge when successful.
• Feel free to provide a TODO list or update it on the fly.
• Interrupt with Esc if the agent's thinking is off-track.
• When agents struggle, write tools to help them, e.g. JSON splicing, Excel edits, etc.
• Agents bloat code and features. Explicitly refactor and trim.

• Use vibe coding for stuff you don't need to maintain.
• Use vibe coding for stuff you know well enough to review quickly.
• Use vibe coding for independent tasks where you're not fussed which ones fail.
• Vibe coding turns everyone into a team lead. That needs skills: planning, allocation, design, review, feedback, ...
• ⭐ Empathy enables vibe-coding. Empaths allocate work by ability, review regularly, and provide detailed specs and feedback.
• Have LLMs plan and allocate tasks.
  • "Read this repo. Suggest improvements." (Review.) "Add these as issues."
  • "Add the top 3 Sentry log errors as issues."
  • "Find the easiest issue and solve it with a PR."
• Use GitHub issues extensively for planning.
• ⭐ Create a separate GitHub account for your agent! Let it push. Assign it issues. Treat it like an intern.
• Ensure agent passes test cases and run till the do, or report the core difficulty.
• Throw away rubbish code and start again.
• Issues unsolved in 2-3 tries are too hard for agents or are poorly spec-ed.
• The context7 and Sequential Thinking MCPs are useful.

• Estimating tool capability & task allocation
• Task breakdown
• Spec-ing: which of user personas, user-journey maps, wireframes, technical architecture, psuedo-code
• Standards: tech stack, tools, linters, security, doc standards
• Git versioning & collaboration
• Code review. (Using AI.) Providing feedback. Modularity, naming, ...
• Automated validation
• Post-mortem. Learning from errors and successes, choices LLM made

1. User enters their scenario in textbox (e.g. "Synthetic data to demonstrate credit card fraud using transaction data. Mid-sized, multiple tables, complex. Excel file")
2. Click "Submit". This should send the scenario to an LLM asking it to
   • Think carefully and identify a schema, stating assumptions (e.g. number of rows to generate, table/column inter-relationships, output file format, etc.)
   • List typical real-world behaviors that could be incorporated into the data and will lead to positive results when testing these hypotheses (e.g. transactions over $10,000 are more likely to be declined, overseas transactions in low-income countries have high failure rates, etc.)
   • Write Python code that generates a random dataset in line with the above, writes the output to a bytestream and returns the filename and bytestream
3. Stream the response. Render it as markdown. Use highlightjs to syntax-highlight the code block using a dark theme.
4. Run the code in the browser using Pyodide, generate the output, and allow the user to download it
5. Allow the user to enter changes in their scenario. Have the LLM make changes to the code by sending the change and the original response. Repeat from step 3.

• Commands are used for:
  • Requirements: Research sub-agent, task breakdown into todos.md, creating specs.md from todos.md
  • Progress tracking: session logging, effort tracking, updating status, planning next steps
  • Project setup: initializing, adding deps, scaffolding features
  • Development: code review, debug error (five whys), explain code, refactor code
  • Optimization: optimize build, DB, caching
  • Testing: TDD, generate test cases, set up unit/integration/E2E testing, analyze coverage
  • Security: security audits, dependency vulnerability scans
  • Integration: sync tasks between GitHub and Linear (two-way issue synchronization, PR linking)
  • Deployment: prepare releases, hotfix deploys, rollbacks, containerization, CI pipeline setup
• Patterns of usage
  • Sub-agents
  • Command handoffs, i.e. one command invoking another
  • Shared among a team in a repo, enforcing standards & sharing best practices
  • Integration with specific tools / APIs (e.g. Linear)

• Delete-Driven Development. Keep deleting code until it fails, then rebuild minimally.
• No-Editor Coding. Pure prompting to build, test, and deploy the app.
• Audience-Sourced Prompt ETF. Collect micro-prompts from audience. Run in parallel. Evaluate against tests. Create index of top prompts. Compare with expert.

• Context engineering
• Documentation
• Automated testing
• Standards
• Capabilities of platforms
• Modularity (and DRY vs WET)
• Code composition
• Code reviews

• claude --debug shows what Claude Code is doing behind a scenes -- and is a good way to understand hidden / undocumented features.
• At the end of each session, ask Claude Code: "Document learnings. What failed? What worked? What's next?"
• Have Claude Code write its own prompts by having it launch sub-agents and create common commands in .claude/commands/.
• Symlink CLAUDE.md, AGENTS.md and GEMINI.md into a CONVENTIONS.md
• Prefer creating tools / writing scripts to analyze data and feed results -- reduces input tokens.

• O3 is better at finding bugs than Jules, which tends to try and fix them rather than discover them.
• Codex writes more minimal edits in PRs than Jules, which is more verbose.
• Claude Code remains the best at faithfully creating and updating front-end apps.

• Make quick edits to repos that are not on your system (e.g. other people's repos, or via others' machines.)
• Run public workshops with a full coding environment.
• Give students assignments that have dependencies pre-installed.
• Collaborate on a work-in-progress codebase with my team.
• Share POCs with clients or public allowing them to edit it.
• Allow teams to install remote AI code extensions (e.g. Windsurf) that may be blocked inside the corporate firewall?

• Recurse center (Brooklyn, online) is a 6/12 week free self-driven programmer retreat. Runs every 6 weeks. You can do whatever you pick. There are daily standups for accountability. The groups are diverse. You can pair with them, pivot ideas, whatever. Principles: push yourself & learn.
• Western education techniques (e.g. spaced repetition, adaptive learning) are very much present in Indian coaching systems, though not known by those names. However, interventions are hard since class 12 students just don't have enough time.
• Coaching classes are a social phenomenon. It's not the smart students who are pulling in their friends. Smart students actually follow the popular students. (Coaching classes are below the typical smart students' standards.)
• Monetizing coaching is hard. People don't want to pay for advice, and welcome free advice only if they ask for it. Coupling with execution is necessary.
• Aider's integrations make it more powerful than Cursor/Windsurf. It auto-lints, runs test cases. Allows different models for "architecting" (generating changes) vs "editing" (applying code). It reads from the screen logs. Context is manual, not automated. Uses an ai! comment to trigger changes and ai? to ask questions.
• Cline.bot is another Cursor-like open source AI code editor that's a VS Code plugin.
• When coding with LLMs, a useful workflow is: data schema ➡️ interfaces ➡️ LLM-generated test cases ➡️ code.
• ShellSage is a tmux based LLM tool for the command line. It screen-grabs from tmux, which is powerful.
• Some MCPs that have proven useful: vega-lite, SQLite, sequential thinking, memory
• make sucks but is hard to beat. just comes closest.
• CRDTs are more powerful than for just collaborative editing. It can power a peer-to-peer Internet (beginning with office tools). Versioning schema is still problematic. yjs is a good start but automerge (Rust, WASM) is faster and may be better.
• Fermyon hosts WASM serverless functions.

• Passing code execution as a tool is more powerful than granular tools. You combine multiple tools and tool calls into one. You move code to the data rather than the other way around. Mostly, you need bash, Python (or Jupyter), file manager, web browser.
• UI: Go where the user is, instead of bringing them to you.
• A remote runtime is a critical component.
• Claude 3.5 Sonnet (20241022) and Claude 3.5 Haiku (20241022) perform best on SWE Bench, followed by Deepseek V3, then O1 2024-12-17. X

• Get THE domain expert (or approver) as the tester.
• Create a dataset that is DIVERSE.
• Covers EACH combination of:
  • Features
  • Scenarios: e.g. multiple matches, no match, ambiguous request, invalid/incomplete input, unsupported feature, system error
  • Persona: e.g. new user, expert user, non-native speaker, busy professional, technophobe, elderly user
• Generate data using existing data + synthetic data for each SPECIFIC combination of the above
• Evaluate based only on PASS/FAIL with a CRITIQUE detailed enough for a new employee. Include:
  • Nuances: Something a failed response did well or a passed response didn't quite do well
  • Improvements: Suggest how model can improve
• Build an SPA to make it easy for the domain expert to review

• Github Copilot
• Cursor
• Cody
• Continue.dev (supports OpenRouter)
• Aider (supports OpenRouter)
• Maybe:
  • Codeium
• Not:
  • Amazon Q Developer

• This is fundamentally altering the programming paradigm by which we iterate on our software, as the teams split in two:
  • the 2.0 programmers (data labelers) edit and grow the datasets, while
  • a few 1.0 programmers maintain and iterate on the surrounding training code infrastructure, analytics, visualizations and labeling interfaces.
• Adaptive UI ideas:
  • Adaptive Fields: Show only required fields based on what the user field so far.
  • Smart Inputs: Dropdowns and auto-complete based on user's context.
  • Smart Themes: Change font size, contrast, theme guessing the user's age and preferences.
  • Dynamic Menus: Show what they might need to do next. Like Nokia's right button, but using LLMs.
  • Smart Tooltips: Check what the user's doing (delays, confusions, previous clicks, current actions) and show relevant tips.
  • Personalized Layout: Show only the relevant sections of the app. E.g. based on what they're doing.
  • Smart Charts: Create the right chart that solve the user's question.
• Adaptive Back-end
  • Dynamic APIs: Create endpoints on the fly based on user needs
  • Dynamic Indexing: Create & update indices on the fly based on user needs
  • Dynamic Schema: Create & update schema on the fly based on user needs
  • Dynamic Migration: Migrate to a new database or OS or language as required
  • Dynamic Queries: Create SQL/NoSQL queries to solve the user problem
  • Dynamic RBAC: Figure out who needs permissions and why. Add OR REMOVE access as required
  • Dynamic Logging. Log what's required. Explain why it's logged and what's happening. Fix code that raised the error
  • Dynamic Caching. Cache what's likely to be required. Evict what may not be required. Figure out cache keys.

• Vaishnavi and Ranjeet edited code
• Indal and Koustav didn't

• Claude Artifacts Prompt
• Val.Townie system prompt. Good example of how to create
• Cursor editing
• Cursor debugging
• Cursor conversation

• Cognition
• Factory
• Codegen

• Write tests that make people think! Like DuckDB workshop
• Share a list of exercises that people can explore

• "Pre-mortem" is an analysis at the beginning of how a project failed. Then avoid that
• "Red team" or "Black hat" are designated to contradict.

• Databuck by FirstEigen. Autolysis plus monitoring
• Quality council has the data steward (maintainer of each dataset) coming together with the uses on a weekly basis to understand what quality problems to users are facing. Data owners jaundice at a lower frequency to get an understanding
• Automate rules for data quality in our projects and intranet
• Convert a config rule into business language. Explain SQL. These are good use cases for llm's
• Graph DBs are powerful for flexible data structures, but query generation needs AI or expertise. Check the Neo4J language cypher
• Explore storing SAME data in relational DBs AND in graph DBs / document DBs for different use cases
• Dallas rocketry challenge. Build a rocket that can take an egg to 800 feet exactly and land without breaking it