#growing #research-piece #ai In this note, I want to capture ideas on "vibe coding" i.e the extensive use of AI agents to write code while the human being acts as a manager of the agents. This note is going to look like a working document. Every time I come across an interesting talk or article around this idea of agent assisted coding, I will write it up in here. ![[vibe-coding.png]] ## What is Vibe Coding? "Vibe coding" refers to the idea of developing software with the help of AI. You provide the vision, AI does the coding. You tweak the code, you develop the product. This was coined by Andrej Karpathy. ![[karpathy-vibe-code-tweet.png]] ## [Article: Where's the Shovelware? Why AI Coding Claims Don't Add Up - Mike Judge](https://open.substack.com/pub/mikelovesrobots/p/wheres-the-shovelware-why-ai-coding?utm_campaign=post-expanded-share&utm_medium=post%20viewer) In this piece, Mike Judge argues that AI coding does not increase productivity. He rubbishes the tall claims made by AI personalities such as Sam Altman that AI makes developers "10 times more productive". Here is a summary of what the article is about and since I do not completely agree with the points, I have also added in some critical points which I believe Mike has missed in his analysis. ### Why does the author feel that AI coding tools do not make developers productive? Mike's core argument is simple - if AI coding tools truly made developers dramatically more productive, we would see it in the only place that matters, **shipped software**. We do not. He starts by questioning his own intuition. After reading the [METR study showing developers overestimate AI productivity gains](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), he runs a six-week self-experiment on himself. The METR study found something striking: developers actually took 19% longer to complete tasks with AI tools, yet perceived themselves as 20% more productive—a clear disconnect between perception and reality. At the end of his own experiment, he finds that personally there was no evidence to show him being at least 2x productive, let alone 10x. He then zooms out with a reasonable proxy to developer productivity - new software. If AI tools were genuinely accelerating development across the industry, we would see a surge in output: more apps, more games, more websites, more repos, more domains. Instead, release data from app stores, Steam, GitHub activity, and domain registrations do not show any such increases since the advent of AI assisted coding. There is no post-2022 inflection point. No shovelware flood. No indie boom. Nothing that signals a step change in production. That absence is the article’s strongest claim. It reframes the debate away from self-reported productivity and toward observable outcomes. It also treats the claims of productivity as vanity metrics and words thrown around to impress investors. Judge also calls out the human cost. Companies are making layoffs, salary decisions, and “AI-first” mandates based on unproven assumptions. Developers are pressured to adopt tools that often feel clunky and cognitively expensive, then blamed when results do not materialise. The conclusion is blunt: developers are not shipping more than before, and claims of AI-powered 10x engineers do not hold up under scrutiny. Until someone can show shipped output at scale, the hype should be treated as marketing, not reality. ### My points of criticism While I fundamentally do agree with the claims being over-exaggerated, I do believe Mike is being a bit too harsh on the idea of AI coding. #### Shipped software is not the "only" metric that matters. First things first, I do not agree with the idea that "shipped software" is the only metric that matters. The article implicitly equates productivity with net new shipped artifacts like apps, games, domains, repos. That is a very narrow definition. Mike does acknowledge that most software development is not just typing code, but he dismisses this mainly by focusing on solo developers and indie output. What he does not account for, based on his own text, is that much engineering work, especially in enterprises, is maintenance, refactoring, migration, compliance, data pipelines, internal tooling, and incremental change. None of that reliably shows up as "new shovelware." His claim that "that's the only metric that matters" is an assertion, not something he proves. From the article alone, you can say the proxy is incomplete. Flat output does not logically imply flat productivity if effort is being redirected toward keeping existing systems alive, safer, or cheaper. However, this explanation requires evidence. Are companies actually redirecting effort toward maintenance in measurable ways, or has effort simply become less productive despite AI tools? If AI truly accelerates development, we should see *something* change—whether that's faster maintenance cycles, more frequent releases, or better uptime metrics. The absence of observable change in *any* metric remains suspicious. Also, to "ship" full software means to handle a bunch of incredibly complex requirements. Just because there is an AI tool available, it does not mean that ever developer would like to create a new product using this tool. Maybe the developers who like to build have continued to build, with maybe some use of AI assisted coding. #### You can't deny individual productivity gains, especially for less experienced developers. Mike’s critique is aimed squarely at aggregate claims like 10x developers and industry-wide acceleration. He does not seriously engage with the possibility of uneven gains. In fact, his own framing allows this gap. He shows that averages are flat and that self-reported gains are unreliable, but that does not rule out local improvements for specific groups. Juniors, PMs, or non-specialists are not the population he tested. His experiment is one highly experienced engineer (he has almost 28 years of coding experience under his belt!) measuring himself. From the article alone, it is not valid to generalise that outcome to everyone. I understand that the reliance on AI coding tools would create poorer engineers in the long term. However, I also feel this is not something that can be solved by bashing all AI coding. This is where "personal responsibility" should show up. That is my next point. #### Personal responsibility is the way. Not blanket rejection of AI coding. I have a colleague who is a PM. On a recent work trip, he showed me an app that he had built from the ground up as a passion project. As someone who claims that he has a limited technical background, its remarkable how he managed to create this application from scratch, and so quickly. And whilst he does not understand the tech workings a lot, he knows enough to explain what is going on. He did not "have to" understand databases or API calls. But he did. He "owned" his product and is approaching it from an angle of *This is my baby. I need to know everything about it to nurture it.* This shows personal responsibility. While this is one encouraging example, it doesn't speak to the broader question of whether AI coding requires exceptional personal responsibility from everyone, or if it could be adopted more casually with acceptable results. But to the extent that individual developers do take ownership, I think the job becomes a lot more fun and engaging. Not everyone writes code because they love it. Some just do so because its important to bring their vision to life. ## [Talk: From Vibe Coding to Vibe Engineering: Navigating the AI-Assisted Development Revolution - Kitze](https://www.youtube.com/watch?v=JV-wY5pxXLo&feature=youtu.be) This was a talk in 2025 on YouTube. In the talk, Kitze discusses the evolving landscape of AI-assisted development and he is a really funny guy! So, I highly recommend watching the talk. According to Kitze, the conversation around AI-assisted development has evolved significantly beyond simple code generation. He points towards Karpathy's "vibe coding" tweet to show the fundamental shift in how developers of the modern day are expected to develop. Kitze observes that there is an increasing push from the industry and tooling providers to adopt more AI-assisted approaches to development. There were quite a few very interesting ideas raised by Kitze and I have broken them up into their own small sections in here with the help of Gemini + Claude[^1]. ### Understanding the Spectrum There's a crucial distinction between "vibe coding" and what Kitze calls "vibe engineering." While vibe coding represents the exploratory end of the spectrum, useful for rapid prototyping and throwaway weekend projects, vibe engineering is something else entirely. It's the practice of experienced engineers using AI agents while maintaining rigorous technical oversight and a healthy level of suspicion about the output. This distinction matters because professional software development isn't just about churning out code and features - it requires creating code that demonstrably works, can be understood by other humans and machines, and supports continued development while considering performance, accessibility, security, maintainability, and cost efficiency. The reality is nuanced. By March 2025, Y Combinator reported that 25% of startup companies in its Winter 2025 batch had codebases that were 95% AI-generated, reflecting a significant shift toward AI-assisted development within newer startups. However, this rapid adoption has come with growing pains. In September 2025, Fast Company reported that the 'vibe coding hangover' is upon us, with senior software engineers citing 'development hell' when working with AI-generated vibe-code. So much so that there is now a potential market for "vibe coding specialists". Literally after the talk I just googled vibe code clean up specialists and there were a bunch of articles around that. This particular website caught my attention and I decided to screenshot and post it here! ![[vibe-code-cleanup-consultancy.png]] >[!danger] My honest thought on vibe coding cleanup > Sounds like a real job given the current trend. But, I am not sure if this is a job for the future or if it is something that will die out soon as models get faster OR devs use models better. ### The PA Dev Paradox One of the most interesting observations from the talk centers on what Kitze calls the "PA Dev" (Pain in the Ass Developer). These are senior engineers who are overly religious about minor details and resistant to AI tools. These are the developers who nitpick about tabs versus spaces, who spend hours in code review arguing about stylistic choices, who resist anything that challenges their established workflows. They also tend to be quite against the idea of AI-assisted coding. Kitze argues that ironically, these are precisely the developers who would see the most significant productivity gains if they embraced vibe engineering. The reason is straightforward - **their deep technical knowledge is exactly what's needed to effectively supervise and direct AI agents**. They have the expertise to quickly spot when AI output is structurally unsound or when it's making subtle errors that less experienced developers might miss. ### The Power of Composer Mode [Cursor's Composer](https://cursor.com/blog/composer) represents a significant advancement in this space - a frontier model that is 4x faster than similarly intelligent models, built specifically for low-latency agentic coding and completing most turns in under 30 seconds[^2]. What makes Composer particularly powerful is that it puts developers back in the "driver's seat," allowing for rapid iteration and refactoring that feels like real coding rather than just waiting for a slow LLM to finish. Composer has progressed Cursor's AI code assistance from just editing single lines of code and individual pages to editing and creating multiple pages at once. This multi-file editing capability fundamentally changes the development workflow, enabling developers to make system-wide changes with the same ease they previously had for single-file edits. ### Practical Approaches to Vibe Engineering **Voice Coding as Context Enhancement**: The recommendation to use voice for "brain dumping" prompts is particularly insightful. By describing the UI to the AI as if talking to a friend and narrating your thinking process, you provide richer context for the agent to work with. This conversational approach often captures nuances and intentions that would be lost in terse text prompts. Basically, if you are too lazy to type, just talk! **The Junior Developer Trap**: The warning against giving AI tools to interns or juniors without foundational knowledge is critical. When developers rely exclusively on AI without understanding the generated code, it can lead to blind spots - not fully understanding the generated code or missing subtle bugs - so human validation and testing remain critical. Without the ability to judge whether output is "good enough" or structurally sound, junior developers can inadvertently introduce technical debt and security vulnerabilities. **Starting with Solid Primitives**: For AI to be effective, you need to provide it with a solid starting point. This means having good components, clear architectural patterns, and well-defined functions that the AI can reference and build upon. The quality of your existing codebase directly impacts the quality of AI-generated additions. ### AI Code will eventually become Legacy Code Kitze makes a prediction that today's modern frameworks will become tomorrow's legacy systems. Senior engineers will eventually become "React Cowboys," similar to modern [COBOL maintainers](https://cobolcowboys.com/), fixing the 20% of code that AI couldn't get right. This comparison to COBOL is more apt than it might initially appear. Currently, approximately 43% of banking systems still rely on COBOL as of 2025, and 95% of ATM swipes are processed using COBOL-based systems. With 220 billion+ lines of COBOL code still in operation and 1.5 billion new lines written annually, maintaining system stability is a massive task as many COBOL experts are nearing retirement and few younger developers are learning the language. The parallel is clear: as AI generates more code, the ability to understand, maintain, and fix that code becomes increasingly valuable. The developers who can navigate both the AI-generated landscape and the underlying technical fundamentals will be the "COBOL programmers" of the future. Rare, valuable, and essential for keeping critical systems running. ### The Employment Landscape Shift The suggestion that the profession will "thin from the bottom" is already playing out in the market. A 2024 study spanning three randomised trials with approximately 4,800 developers across Microsoft, Accenture, and a Fortune 100 firm found that using GitHub Copilot led to a 26% increase in developer productivity on coding tasks, with less-experienced programmers benefiting the most as they more readily adopted the AI suggestions. While senior roles appear safe for now, the barrier to entry for juniors is rising because companies may increasingly replace entry-level tasks with AI agents. This creates a tension that's worth examining carefully: if entry-level work disappears, junior developers might need to learn by tackling higher-complexity problems earlier, or alternatively, they may lack the scaffolded learning that traditional entry-level roles provided. Whether this creates a genuine talent bottleneck or simply changes the learning trajectory remains unclear. ### The Technical Skill of Staying Updated The closing reminder that being "chronically on Twitter" and staying updated on new models is currently a required technical skill highlights an uncomfortable truth about modern software development. The pace of change in AI capabilities is so rapid that keeping up with the latest models, techniques, and tools has become as important as traditional technical skills. This represents a fundamental shift in what it means to be a developer. It's no longer enough to deeply understand a specific technology stack; you must also maintain awareness of the evolving AI landscape and continuously adapt your workflows to leverage new capabilities. ### Looking Forward The transition from vibe coding to vibe engineering isn't just about adopting new tools - it's about developing a new mindset that balances automation with expertise, speed with scrutiny, and innovation with reliability. The developers who thrive in this new landscape will be those who can effectively supervise AI agents, maintain deep technical knowledge, and adapt quickly to rapidly evolving capabilities. As one security professional noted, vibe coding is reshaping development workflows by making AI an active collaborator rather than a passive assistant, which accelerates productivity but introduces new security risks that traditional security processes struggle to keep up with. This means that effective vibe engineering requires not just technical skill but also constant vigilance and a commitment to code quality that goes beyond simply accepting AI output. The future likely belongs to those who can navigate this complexity i.e developers who understand both the power and limitations of AI assistance, who can quickly iterate while maintaining high standards, and who view AI as a powerful tool to be directed rather than a replacement for human judgment and expertise. ### Other reading from the web used to understand this talk more deeply 1. [Vibe coding - Wikipedia](https://en.wikipedia.org/wiki/Vibe_coding) 2. [Vibe Coding Explained: Tools and Guides | Google Cloud](https://cloud.google.com/discover/what-is-vibe-coding) 3. [Not all AI-assisted programming is vibe coding (but vibe coding rocks) - Simon Willison](https://simonwillison.net/2025/Mar/19/vibe-coding/) 4. [Introducing Cursor 2.0 and Composer](https://cursor.com/blog/2-0) 5. [What's Cursor Composer? How to Build Full Apps with AI](https://prototypr.io/post/cursor-composer-cmdi) 6. [AI-Assisted Software Development and the "Vibe Coding" Debate - Cybersecurity Advisors Network](https://cybersecurityadvisors.network/2025/08/06/ai-assisted-software-development-and-the-vibe-coding-debate-by-nick-kelly/) 7. [2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders](https://www.pragmaticcoders.com/resources/legacy-code-stats) 8. [Why COBOL Programmers Are Still in Demand in 2025 | Medium](https://medium.com/@integrative-systems/why-cobol-programmers-are-still-in-demand-in-2025-0548ae5d1f81) 9. [Vibe Coding: Leveraging AI-Assisted Programming - Cycode](https://cycode.com/blog/vibe-coding/) 10. [Original YouTube Video: From Vibe Coding To Vibe Engineering](https://www.youtube.com/watch?v=JV-wY5pxXLo) 11. https://andrewchen.substack.com/p/predictionsthoughts-on-vibe-coding 12. https://news.ycombinator.com/item?id=43218410 ## [Talk: The Infinite Software crisis - Jake Nations, Netflix](https://www.youtube.com/watch?v=eIoohUmYpGI) This was another talk released on the AI Engineer YouTube channel as part of AIWEF 2025. In this talk, there is a discussion around what the future of software engineering would look like with AI. I really like this talk because the speaker, Jake Nations (Netflix) is not posturing. He opens by admitting he's shipped code he didn't fully understand - generated it, tested it, deployed it. And he's right that we've all done it. There's no preaching about how AI coding sucks or how it's the future. Just a grounded recognition that AI coding can be really good _if used well_. But of course, we all know that as smart modern-day programmers[^3]. What really stands out in this talk are a few key, "simple" ideas Jake raises that makes the conversation around AI-assisted coding a lot clearer. ### The Difference between Simple and Easy Nations leans heavily on [Rich Hickey's distinction of simple and easy here](http://www.youtube.com/watch?v=SxdOUGdseq4)[^4]. The core idea is this: "Easy" is about proximity - what's within reach, what requires no effort. "Simple", though, is about structure - things that have one role, one task, one objective, not braided together with other concerns. ![[rich-hickey-simple-easy.png]] *Image, quite obviously AI-generated haha*. An AI prompt is the ultimate easy button. But easy doesn't mean simple. Simple is objective - you can look at code and see if things are intertwined or not. Easy is relative - it depends on what you're already familiar with. The trap is clear - **AI-assisted coding makes things easy, not simple**. It'll generate working code instantly, but that code might be structurally complex, tangled, hard to maintain. The ease of generation doesn't translate to simplicity of architecture. Every time we choose easy, we're choosing speed now and complexity later. Making something simple requires effort - you have to untangle the web of knots. Making something easy just means bringing it closer or becoming familiar with it. ### Complexity needs to be earned. AI just adds it in anyways. Jake argues that complexity needs to be earned through understanding. With the use of AI chat interfaces (like Cursor), things get complex too quickly, too fast. The problem is that AI doesn't distinguish between **essential complexity** (the actual problem you're solving) and **accidental complexity** (legacy hacks, technical debt, workarounds). To AI, it's all just code. It sees patterns and replicates them. >[!danger] Personal example >I have not seen this play out in code, but I did see it when trying to generate some Confluence documentation for a project. AI just loves writing and it wrote a lot. But, too many words and the docs just become a nightmare to read. Nobody wants to read a novel when reading tech docs. And once AI wrote all that up, cleaning it up was harder than just writing up all docs again from scratch and then asking AI to clean up my spellings and grammar and profanity. > [!note] Note > Technical debt doesn't register as debt to an AI. It's just more code to learn from and replicate. ### Context Compression: The 3-Phase Framework Nations proposes a workflow to keep human oversight at the speed of AI generation: 1. **Research** - compress millions of tokens (code) into human-readable documentation 2. **Planning** - create a **validated spec** that humans can review in minutes 3. **Implementation** - AI executes the **pre-validated plan** >[!tip] This framework was introduced by Dex Horthy in his talk [No Vibes Allowed: Solving Hard Problems in Complex Codebases](http://www.youtube.com/watch?v=rmvDxxNubIg), again at AI Engineer 2025. That was a very interesting talk which I am currently using as theoretical grounding for an agent I am trying to create. So, hopefully analysis of this talk too will show up as another note sometime in the not-so-distant future. ### Why This Talk Makes So Much Sense To Me What I appreciate about this talk is that Jake is working at a massive company, shipping real products, and he's not pretending there's a silver bullet. He's also not doing what some devs want to do - showing a middle finger to AI and treating it as mere hype. We all know AI coding has problems. But we can't just deny it. It's here, it's getting better, and we need to unlock better workflows rather than just complaining. The developers who thrive won't be the ones who generate the most code - they'll be the ones who can still see the seams, who maintain the instinct for what makes a system maintainable. Jake also has some lovely quotes. Here are my favourites! >[!quote] The hard part was never typing the code. It was knowing what to type in the first place. >[!quote] AI accelerates your thinking. >[!quote] There is no silver bullet - Not better prompts, not better models, not even writing specs. Just the unavoidable work of understanding your system deeply enough to change it safely. ## [Talk: Developer Experience in the Age of AI Coding Agents - Max Knat Alexander, Capital One](https://www.youtube.com/watch?v=rT2Del5pwg4) In this talk, Max discusses the "no-regret" investments we can make to help developers in the age of AI-assisted development. The discussion is important given the current state where there are "new things" being launched every other day which most teams are also keen on getting their hands on and using, even if the tech is new and unstable. There are two key questions we need to ask with creating new tooling for agents - What will be valuable no matter what happens? - What do we need to do to get maximum value from agents? ### The "No-regret" Investments These are the "inputs" to agents to help them better interface with codebases. #### Standard Development Environments - Use industry standard tools, frameworks and languages; and use them the way the industry uses them - Use these consistently across the same company - The reason - These "standards" are part of the LLM's training set. So, it is more likely to provide better outputs as its not "niche" #### CLIs and APIs - Agents need tools to take actions or validate their work - These CLI commands should run at development time, not just CI as part of deployment #### Validation - Agents produce better with objective, deterministic validation - Failures should have clear actionable messages so the agents or humans can pick issues up #### Code Simplicity - Agents work better on better-structured codebases - These codebases need to be "clean" and also designed in a testable fashion #### Written Information - Docs tell the agents the context around the program and why the code was written - Developer intention needs to be documented as the agents can't mind read[^5] #### Code Review Velocity >[!quote] We spend more time reading code than writing code. But, today writing code has become reading code. Every software engineer becomes a code reviewer. - Make each individual response faster, not the whole process - Assign reviews to specific individuals and set SLOs - Make it clear whose turn it is to take action With these no-regret investments added in, teams can help skip the vicious cycle of bad code and low quality reviews feeding the beast and making a much worse codebase. Also, with better tooling and a good codebase (or continuously improving codebase), and strong reviews, the team's velocity will improve a lot. And teams will ship quality features faster. Max signs off with the idea - *What is good for humans is good for AI*. The message he looks to convey here is investment in these "no-regret" tooling for AI-assisted coding is also going to help the people on the team and not just the AI. ## [Talk: Amp Code: Next Generation AI Coding - Beyang Liu](https://www.youtube.com/watch?v=gvIAkmZUEZY) Amp is defined by Beyang as an opinionated frontier agent, built on the philosophy that AI-assisted coding has shifted from manual editing to writing code through the agent panel. In this model, the developer acts more as a reviewer, using a specialised interface to guide the agent’s work. #### Tooling Strategy: Custom Tools over MCP While the industry is moving toward the Model Context Protocol (MCP), Amp takes a contrarian stance. They focus on a refined, custom toolset rather than broad MCP integration. This prevents context confusion - where too many irrelevant tools clutter the agent’s decision-making process - and allows the team to tune tool descriptions specifically for the agent’s feedback loops. #### Managing Context via Subagents To solve the doom loop where agents run out of context window during large tasks, Amp uses Subagents. Similar to subroutine calls in programming, subagents factor out specific tasks into their own context windows, returning only relevant results to the main agent. Amp utilises four core subagents: - The Finder: Specialised for codebase search - The Oracle: Handles deep reasoning and nuance, keeping the main agent snappy - The Librarian: Fetches external context from libraries and frameworks - The Kraken: Executes large-scale refactors via code mods ![[amp_agents.png]] #### Architecture: Smart vs. Rush Amp rejects the standard model selector UI, citing the paradox of choice - the cognitive burden of choosing models prevents users from optimising for a specific model’s strengths. Instead, Amp provides two top-level agents: - Smart: A slower, high-frontier model for complex planning - Rush: A fast, in-the-loop model for quick, targeted edits ![[amp_arch.png]] #### Modern Inerface and Collaboration - Terminal: Amp features a custom TUI framework built from scratch to leverage modern terminal rendering. - Editor as Reader: Within the editor, Amp provides a tour of the change, guiding users through diffs because the primary human bottleneck is now code review, not writing. - Share Threads: Developers can share URLs to specific agent threads with teammates to exchange prompting techniques or debug stuck states. #### Economic Accessibility To lower the barrier to entry, Amp introduced a non-obtrusive ad network within the terminal. These ads sponsor the inference costs for the Rush agent, making high-quality agentic coding accessible for free on side projects. Personally, I love this! ## [Talk: Making Codebases Agent Ready - Eno Reyes](https://www.youtube.com/watch?v=ShuJ_CN6zr4) Eno Reyes from Factory AI makes a somewhat interesting observation around AI-assisted coding. The real bottleneck, he argues, isn't whether the AI models are smart enough. It's whether your codebase is ready for them. The core insight here echoes back to [Andrej Karpathy's "Software 2.0" idea](https://www.oreilly.com/radar/the-road-to-software-2-0/): it is genuinely easier to verify a solution than to create one. When you set a clear objective and let an AI search through possibilities, good things happen. Software development is uniquely suited for this because you have automated testing, linters, and all sorts of measurable validation mechanisms built in. But according to Reyes, orgs don't often get this when they deploy agents to work with codebases. Orgs run agents on codebases that are designed for human tolerance. 50-60% test coverage? Flaky builds that the team has learned to navigate around? Sure, a developer can muscle through that. An AI agent can't. When the validation is that loose, the agent doesn't know what "correct" actually looks like. It just generates something plausible, and without clear guardrails, plausible isn't good enough. The difference becomes obvious when you look at scale. Tech giants like Google or Meta can trust new graduates to ship code quickly not because the graduates are extraordinary, but because the automated validation is so rigorous it catches catastrophic failures before they happen. It's an environment where agents could theoretically thrive, if they existed[^6]. The traditional software development loop is - understand the problem, design a solution, code it, test it. The AI-native loop is, in theory simpler - specify what "correct" looks like, let the agent generate solutions, verify them (both automatically and through human intuition), iterate. Instead of designing solutions, the engineer is now defining constraints and validation criteria. Personally, this does sound like common sense. It's been the aspiration for a lot of engineering teams - the idea of building the perfect system for devs to build and not break things. It's pretty much the idea of the pure software engineering development lifecycle. What strikes me about this framing is how it maps onto what Max Knat Alexander was saying about "no-regret investments" (see above). Eno makes the point that many companies spend weeks comparing AI tools when they should be spending that time fixing their validation infrastructure. And here's the kicker: when you invest in better tests, better linters, better documentation, every single AI tool you use gets better. It's a universal win. Code reviewers get smarter, agents get smarter, and even your human developers benefit because they're working in a cleaner environment. The implication is almost subversive. One thoughtful engineer who cares deeply about validation and architectural opinions can now meaningfully shape the velocity of an entire business. Not by writing more code, but by setting high standards that agents then follow. The role shifts from "code producer" to "codebase gardener," someone who cultivates the conditions for good code to flourish, whether that code is written by humans or agents. Eno ends with a (deliberately) provocative claim - fully autonomous loops are technically possible right now. A bug ticket gets filed, an agent identifies and fixes it, automated verification confirms it works, and the code ships, all within an hour. The 5x to 7x productivity gains people talk about? They're not blocked by AI capability. They're blocked by a team's ability to define what "correct" looks like with enough clarity that a machine can verify it. ## [Article: Ready for AI - Preparing your codebase for assistants](https://wearehypercube.com/ready-for-ai-preparing-your-codebase-for-assistants/) Five key points from this piece by Jamie Smith at Hypercube. 1. Add `AGENTS.md` Documentation - Create a concise guide explaining your codebase's purpose, entry points, and key components specifically for AI agents. The focus is on giving minimal context rather than a full system overview. 2. Implement Type Hints - Use type annotations to clarify function inputs and outputs. This makes expectations explicit for both AI assistants and humans about what data flows through the code. 3. Write Executable Tests - Develop test suites that serve as working examples and demonstrate expected behavior. Tests act as "executable documentation" that give AI tools concrete targets to meet. 4. Improve Naming Conventions - Replace vague names with descriptive ones. Clear variable and function names help language models understand intent, enabling more accurate and safer code generation. 5. Streamline Code Structure - Reduce unnecessary complexity like heavy indirection or metaprogramming. A clear entry point and straightforward logic flow makes it easier for AI to follow and extend your application. ## Some Personal Thoughts on Vibe Coding >[!info] >Just ideas I jot down randomly! 1. With more AI being used to write code, task estimation would be an interesting area of project management that will be impacted. Tasks that might have taken 3 days, might now just take a few minutes. 2. Developers might have to focus more on code quality than code production. Everyone will likely need to think like a code curator. 3. Most of knowledge work consists of simple, but time consuming tasks. Exactly the kind of tasks AI can automate. As an industry, is knowledge work going to see massive displacement? Would people simply be moved to new jobs? Where will these jobs be created? Will policy slow down AI use? I don't really have any answers to these yet. 4. Is a "bad AI worker" a lazy one that can't sit down to write requirements with clarity? [^1]: Claude could not view the Youtube video but Gemini did it with ease. Probably a deliberate choice by Youtube? Anyways, for those wondering, this was my workflow - Watch the talk, pass the link to Gemini and summarise the ideas and paste them onto Claude to then engage deeper with a Socratic style of learning + also getting Claude to search the web to provide more relevant references. [^2]: Everyone loves some speed! With agentic coding, low latency means faster interactions. Faster interactions means you feel like you are coding and building something. And not just waiting! [^3]: I am not too sure if I qualify as a "programmer" being more of a data person. But, I am fascinated nevertheless by the world of software engineering and building products! [^4]: Hickey is the creator of Clojure and gave an influential talk called "Simple Made Easy" back in 2011 that's still shaping how people think about software architecture. [^5]: This is where just freely talking to the agent (brain dumping) would be useful during development. Connects back to Kitze's point in his talk. [^6]: This can also in a way be the law of compounding in play with agentic coding. A better codebase => Agents can work better with it => Agents make better improvements => Codebase gets better