Importance of Coding Principles

When you start working on a new (for you) but existing codebase, you will notice patterns you strongly disagree with. Naming conventions that seem stupid. Abstractions that seem over-engineered. Error handling that you would have done very differently. Match them anyway, in the code that you write. A codebase is a shared 'language'. When every file follows the same conventions, you and your peers can move through the code quickly, make changes confidently, and reason about what things do without stopping to decode style differences. The moment you introduce your own patterns, you add a 'second dialect'. Now the next person reading your code has to context-switch mid-file. The cost of diverging is almost always higher than the cost of going along with something imperfect. The original author is not necessarily wrong either - they had context you do not. Try to understand that. There is a right time to change conventions; wait until then. You can always initiate a team discussion or raise a smaller pull request that updates a small fraction of the codebase and demonstrates the benefits. Hope this helps.

In my first coding interview, I was so focused on solving the problem that I didn’t care about how my code looked. Messy variables, no indentation, and zero structure. Guess what? I didn’t clear that round. Turns out, clean code matters as much as the solution. Here’s what we should take care of while writing good code during interviews: ✅ Variable names matter Avoid a, b, or temp. Use meaningful names like maxSum or isPalindrome—it makes your logic easier to understand. ✅ Indentation is important Write code that’s neat and properly aligned. It shows you’re organized and professional. ✅ Write scalable solutions Avoid hardcoding values. Use variables and write code that can handle a range of inputs. ✅ Comments If something in your code feels complex, add a quick comment or explain it to the interviewer while coding. ✅ Keep it simple Don’t overcomplicate your logic. A clear and efficient solution always wins. Your code isn’t just a solution—it’s a reflection of your approach. So, the next time you solve a problem, write like you’re being interviewed. Because clean code == confidence. All the best!❤️

Clean code isn't just about readability —it's about creating maintainable, scalable solutions that stand the test of time. When we prioritize readability, simplicity, and thoughtful architecture, we're not just making our lives easier; we're creating value for our teams and organizations. A few principles that have made the most significant difference in my work over years: • Meaningful naming that reveals intent • Functions that do one thing exceptionally well • Tests that serve as documentation and safety nets • Consistent formatting that reduces cognitive load The greatest insight I've gained is that clean code is fundamentally an act of communication—with future developers, our teammates, and even our future selves. The time invested upfront pays dividends during maintenance, debugging, and onboarding. What clean code practices have transformed your development experience? I'd love to hear about the principles that guide your work. Image Credit - Keivan Damirchi

😅 The biggest AI coding question today: how do you get to production without shipping vibe coded slop? A lot of developers now understand that AI can help them move fast. You can vibe code a prototype, generate a feature quickly, and get a working draft in minutes. But the harder question is, how do you make sure the code actually stands the test of time? This is exactly what Mihail Eric covered in our internal Chai & AI community session last week. Mihail teaches the "The Modern Software Developer" course at Stanford, is Head of AI at Monaco, and was also a colleague of mine back at Alexa. In the session, he introduced his RePPIT framework for using AI to ship production quality code. RePPIT breaks down the coding process into five deliberate steps: (Re)search, (P)ropose, (P)lan, (I)mplement, and (T)est. A few ideas from the RePPIT framework, although I’d recommend reading the whole the whole article we wrote around the session (linked below): ⛳ Research the codebase: Before asking AI to implement anything, first ask it to understand the architecture, file layout, dependencies, design decisions, and existing patterns. This keeps the model grounded in the actual codebase. ⛳ Propose solutions: Instead of jumping straight into code, ask the model to generate a couple of different implementation paths with tradeoffs, validation plans, and open questions. This is where you, as the developer, make the judgment call. ⛳ Plan the chosen solution: Once you pick a direction, turn it into a proper design doc. This helps define what’s in scope, what’s out of scope, what files need to change, and how the feature should be tested. ⛳ Implement the plan: Only after the research, proposal, and planning steps should the model start writing code. At this point, it has enough context to avoid guessing its way through the implementation. ⛳ Test what got built: Don’t let the same model instance blindly approve its own work. Use a fresh context or a different model to review, test, and critique the implementation before you trust it. I think a lot of this boils down to strong context engineering. It was also super useful to walk through a concrete example, which you can see in the article. Article: https://lnkd.in/gG9uF6kC Mihail also runs an incredibly cool course at Stanford as well as on Maven. You can find links to both below!

AI replaced a large part of coding. But it did not replace engineering. Generating code is becoming easier. Deciding what to build, how systems should work, where risks may appear, and what happens after deployment still requires human judgment. Here are 7 skills developers need to master: → 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗥𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 Turn requirements and constraints into scalable, reliable designs while balancing cost, speed, and trade-offs. → 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗧𝗵𝗶𝗻𝗸𝗶𝗻𝗴 Understand how APIs, services, databases, caches, queues, and monitoring work together in production. → 𝗖𝗼𝗱𝗲 𝗥𝗲𝘃𝗶𝗲𝘄 & 𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 Check AI-generated code for wrong assumptions, missing conditions, edge cases, performance issues, and production risks. → 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 & 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 Connect user problems and business goals to feature scope, technical decisions, and measurable outcomes. → 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗔𝘄𝗮𝗿𝗲𝗻𝗲𝘀𝘀 Review permissions, data protection, prompt injection risks, insecure coding, and hidden vulnerabilities before release. → 𝗔𝗜 𝗖𝗼𝗹𝗹𝗮𝗯𝗼𝗿𝗮𝘁𝗶𝗼𝗻 𝗦𝗸𝗶𝗹𝗹𝘀 Give clear context, define tasks well, review outputs, refine prompts, validate results, and reuse proven patterns. → 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗢𝘄𝗻𝗲𝗿𝘀𝗵𝗶𝗽 Monitor logs and metrics, detect incidents, fix root causes, document learnings, and continuously improve the system. AI can generate code quickly. Engineers are still responsible for judgment, reliability, security, architecture, and long-term maintenance. The future belongs to developers who can direct AI and own the outcome. Save this if you are preparing for the next era of software engineering.

AI works much better with full context. That has real consequences for how we build software. We recently moved our backend, frontend, and service config into one monorepo. Not just for developer convenience, but because we want AI coding tools to be useful for real end-to-end work. Before that, a single feature was often spread across multiple places: backend logic, frontend changes, service config, and sometimes infrastructure too. AI could help with parts of the task, but rarely with the whole thing. Without the full picture, you get partial solutions, broken assumptions, and more manual stitching by engineers. Now, around 95% of the code needed for a feature lives in one codebase. That changes a lot. AI can work across boundaries more reliably, follow patterns more consistently, and generate output that is much closer to ready for review. One of my biggest learnings from AI-first software engineering so far: better AI output is not just about the tool. It’s also about the environment around it: codebase structure, shared conventions, clear ownership, and discoverable patterns. If we want AI to produce better output, we need to give it better context. How are you adapting your engineering setup for AI-first development? #ai #softwareengineering #monorepo #developerexperience #futureofwork

Your codebase is the prompt. Most teams focus on writing better prompts for AI. But AI coding tools don’t just read your instructions. They read your code. They learn from the patterns already there. If your codebase is full of shortcuts, inconsistencies, and workarounds AI will reproduce them. The result looks consistent. But it becomes harder to change over time. This is why Clean Code matters more now, not less. Not because humans are writing every line. But because your codebase is what you’re actually prompting with. If you want AI to generate clean code, you first need to make your standards explicit. They should be clear enough that a human understands them and an AI can work with them too.

Anthropic's latest guide is goldmine for AI engineers: (it's about context engineering) A poor LLM can possibly work with an appropriate context, but a SOTA LLM can never make up for an incomplete context. That is why production-grade LLM apps don’t just need instructions but rather structure, which is the full ecosystem of context that defines their reasoning, memory, and decision loops. And all advanced agent architectures now treat context as a multi-dimensional design layer, not a line in a prompt. Here’s the mental model to use when you think about the types of contexts for Agents: 1) Instructions → This defines the who, why, and how: → Who’s the agent? (PM, researcher, coding assistant) → Why is it acting? (goal, motivation, outcome) → How should it behave? (steps, tone, format, constraints) 2) Examples: This shows what good and bad look like: → This includes behavioral demos, structured examples, or even anti-patterns. → Models learn patterns much better than plain rules 3) Knowledge: This is where you feed it domain knowledge. → From business processes and APIs to data models and workflows → This bridges the gap between text prediction and decision-making 4) Memory: You want your Agent to remember what it did in the past. This layer gives it continuity across sessions. → Short-term: current reasoning steps, chat history → Long-term: facts, company knowledge, user preferences 5) Tools: This layer extends the Agent's power beyond language and takes real-world action. → Each tool has parameters, inputs, and examples. → The design here decides how well your agent uses external APIs. 6) Tool Results → This layer feeds the tool's results back to the model to enable self-correction, adaptation, and dynamic decision-making. These are the exact six layers that help you build fully context-aware Agents. 👉 Over to you: Have I missed any context layer in this? ____ Find me → Avi Chawla Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.

After 2,000+ hours using Claude Code across real production codebases, I can tell you the thing that separates reliable from unreliable isn't the model, the prompt, or even the task complexity. It's context management. About 80% of the coding agent failures I see trace back to poor context - either too much noise, the wrong information loaded at the wrong time, or context that's drifted from the actual state of the codebase. Even with a 1M token window, Chroma's research shows that performance degrades as context grows. More tokens is not always better. I built the WISC framework (inspired by Anthropic's research) to handle this systematically. Four strategy areas: W - Write (externalize your agent's memory) - Git log as long-term memory with standardized commit messages - Plan in one session, implement in a fresh one - Progress files and handoffs for cross-session state I - Isolate (keep your main context clean) - Subagents for research (90.2% improvement per Anthropic's data) - Scout pattern to preview docs before committing them to main context S - Select (just in time, not just in case) - Global rules (always loaded) - On-demand context for specific code areas - Skills with progressive disclosure - Prime commands for live codebase exploration C - Compress (only when you have to) - Handoffs for custom session summaries - /compact with targeted summarization instructions These work on any codebase. Not just greenfield side projects! I've applied this on enterprise codebases spanning multiple repositories, and the reliability improvement is consistent. I also just published a YouTube video going over the WISC framework in a lot more detail. Very value packed! Check it out here: https://lnkd.in/ggxxepik

There's a common belief in our industry that technical debt sneaks into a codebase over time, often blamed on external pressure like deadlines, staff turnover, context switches, manager decisions, etc. But is that really what happens? Some of the worst code I've ever reviewed contained thousands of lines of code with God Functions, way too many responsibilities, painful code duplication, implicit dependencies which make every change brittle, excess conditional logic in a shape that's capable of melting your brain faster than a GPU without heatsink -- you name it. How did we get there? Most likely, the code was bad from the start and its future evolution merely dug that hole deeper. The evidence? A fascinating study investigated 200 open source projects for code smells, and then backtracked each of those code problems to identify the commit that introduced the root cause. The surprising conclusion is that such problems are introduced already upon the creation of those classes! 💡 If code problems are present from the start, then our practices and tools need to take that fact into account. However, existing code may of course also turn bad with a single commit. When that happens, the affected code exhibits specific trends that differ from how clean code evolves. (You see an example in the graph). ✅ Collaborate early -- don't wait for a review where it's "too expensive" to reject the complete implementation. ✅ Use strong quality gates for any new code. Automate. ✅ Track evolutionary trends in code health. Act on any signs of trouble. By applying these principles, we prevent technical debt instead of managing its consequences.