--- title: Data Right Next to Your Code | daily.dev description: An essay reflecting on how AI coding agents and reliance on familiar 'starter' stacks have reduced developer exploration and experimentation. The author argues... canonical: https://daily.dev/posts/data-right-next-to-your-code-8pszsmc0t twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Data Right Next to Your Code | daily.dev og:description: An essay reflecting on how AI coding agents and reliance on familiar 'starter' stacks have reduced developer exploration and experimentation. The author argues... og:url: https://daily.dev/posts/data-right-next-to-your-code-8pszsmc0t og:image: https://api.daily.dev/og/posts/8PSzsMc0T.png og:image:alt: Data Right Next to Your Code og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Data Right Next to Your Code **[Trevor Suna](https://daily.dev/sources/emop47rpuw8dnjhp6r1b6)** · [@trevorsuna](https://daily.dev/trevorsuna) · 6 min read · 0 upvotes · 0 comments ## Summary An essay reflecting on how AI coding agents and reliance on familiar 'starter' stacks have reduced developer exploration and experimentation. The author argues that the ease of cloning existing repositories and prompting agents to build on top of known frameworks and databases has replaced the old cycle of discovering, imagining, and struggling with unfamiliar technologies. While acknowledging that shipping fast and using boring, proven technology is valuable, the piece calls for making room for inefficient, exploratory projects that may never ship but preserve the joy of learning something new. ## Content “Data right next to your code.” I saw the title of a technology video, _it was probably a Fireship video_ and clicked immediately. A few minutes earlier, I hadn’t known this technology existed. Now my mind was racing. Could I remove an entire synchronization layer from one of my projects? Could I put each customer’s data closer to where it was processed? Would this simplify that feature I had abandoned months ago? I wasn’t writing any code yet. I wasn’t even sure I understood the technology properly. But I was imagining things—and that was the fun of it. This used to happen all the time. I would discover a language, framework, database, runtime, or architectural pattern that was completely new to me. Then I would spend the rest of the day looking for a reason to use it. Sometimes the technology genuinely fit the problem. Sometimes I was trying to force a very exciting square peg into a perfectly ordinary round hole. Either way, I was exploring. The project in my head would begin changing shape. Features that previously felt difficult suddenly seemed possible. Old assumptions became optional. I would open the documentation, build a small experiment, misunderstand half of it, break something, and eventually experience that wonderful moment when the idea finally worked. I might never ship it. I might decide the technology was completely wrong for the project. The experiment itself was still valuable because I came away with a new way of thinking. Lately, those moments have become rare. ## We only care about shipping The dominant goal in software development now is speed. Ship the prototype. Ship the MVP. Ship before someone else does. Validate the idea before spending too much time on it. Get something in front of users and iterate. None of this is bad advice. Most users do not care whether we enjoyed discovering a new database. They care whether the product works. Businesses cannot fund endless technical experiments, and many developers have learned the painful consequences of choosing exciting technology over boring technology that already does the job. Then coding agents arrived and gave us an extraordinary way to move even faster. We can describe a feature, point an agent at the repository, and watch it produce the implementation. It can create the database migration, API endpoint, interface, tests, and documentation while we review the changes and provide direction. The tedious parts shrink. The distance between an idea and working software becomes shorter. This should make coding more fun. Somehow, it often does the opposite. ## The stack that ate every idea Coding agents work best when we give them a familiar environment. If the repository already has authentication, database access, error handling, components, deployment configuration, and established conventions, the agent can follow those patterns. Its work becomes more predictable, and reviewing it becomes easier. Experienced developers have taken this further. Many of us have created a starter project containing our accumulated decisions: the framework we trust, the database we understand, our preferred authentication provider, the component library we know, and the deployment platform that rarely surprises us. That starter project represents years of lessons. Using it is sensible. So when we have an idea, we clone the repository. Then we ask an agent to build the new thing on top of it. The product name changes. The database tables change. The interface changes. Underneath, it is the same application again. This is wonderfully efficient. It is also a trap. Every new technology now has to compete against an entire working system. Trying something unfamiliar means giving up the authentication that is already configured, the components that already exist, the deployment pipeline that already works, and the patterns our agents can already imitate. Exploration starts to look like unnecessary risk. Why spend a weekend learning an unfamiliar database when the agent can add another table to Postgres in thirty seconds? Why experiment with a different runtime when the current one already has a deployment configuration? Why reconsider the architecture when the starter repository can become an MVP by lunchtime? We already know how to ship. We are just no longer discovering very much along the way. ## The real thing coding agents took away People often describe the effect of AI on programming as the loss of typing. We no longer write every function ourselves. We do less of the slow, manual work that once occupied most of our day. Some developers miss that process, while others are delighted to leave it behind. But typing was never the most important source of joy. The joy came from possibility. It was the moment an unfamiliar idea made an old problem look different. It was opening a blank project without knowing whether the experiment would work. It was struggling long enough with a new concept that your mental model had to change. Coding agents did not take away the pleasure of typing code. They made it easier to stop exploring. They did not force us to use the same stack. They simply made the familiar stack so fast and convenient that every alternative became difficult to justify. We optimized away uncertainty, forgetting that uncertainty was often where the excitement lived. The old loop looked something like this: **Discover. Imagine. Experiment. Struggle. Understand. Build.** The new loop is more efficient: **Clone. Prompt. Review. Ship. Repeat.** The irony is difficult to ignore. We worry that coding agents will become trapped in repetitive loops, producing variations of things they have seen before. Meanwhile, we clone the same starter, choose the same services, issue the same instructions, and build the same application with different nouns. We are not having fun anymore because we are on a loop, just like the agents we use. ## Making room for inefficient ideas I am not going to stop using coding agents. I am not going to abandon a reliable stack simply to make every project more technically adventurous. Shipping matters, and boring technology is often boring because it works. But perhaps not every project needs to begin with maximum efficiency. Maybe some projects should start with an unfamiliar tool rather than a starter repository. Maybe we should occasionally choose a technology before we can fully defend the decision. Maybe learning something that never reaches production is not wasted effort. Exploration requires permission to be inefficient. It needs room for prototypes that go nowhere, architectures that turn out to be wrong, and technologies that solve problems we do not actually have. That can look like wasted time when measured against features shipped. But without those experiments, our experience becomes a smaller and smaller circle around decisions we made years ago. The next time I see a video titled “Data right next to your code,” I do not want to evaluate it only by how quickly an agent could add it to my existing stack. I want to feel that old excitement again. I want to open the documentation, create an empty project, and ask the dangerous question that used to make coding fun: **What could I build with that?** ## Similar posts on daily.dev - [AI Coding Has Made Project-Switching Way Too Easy](https://daily.dev/posts/ai-coding-has-made-project-switching-way-too-easy-f3ssbpadj) · DEV · 2 upvotes · 0 comments - [Get out of your developer bubble to survive the AI bubble](https://daily.dev/posts/get-out-of-your-developer-bubble-to-survive-the-ai-bubble-yj8wtvnig) · Stack Overflow Blog · 0 upvotes · 0 comments - [Your codebase doesn't care how it got written](https://daily.dev/posts/your-codebase-doesn-t-care-how-it-got-written-do0usjgun) · RUBYLAND · 0 upvotes · 0 comments - [We are all juniors again](https://daily.dev/posts/we-are-all-juniors-again-xzjwkpglc) · arkency · 1 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#ai-agents](https://daily.dev/tags/ai-agents), [#ai-coding](https://daily.dev/tags/ai-coding) [View this post on daily.dev](https://daily.dev/posts/data-right-next-to-your-code-8pszsmc0t) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/data-right-next-to-your-code-8pszsmc0t","headline":"Data Right Next to Your Code","text":"An essay reflecting on how AI coding agents and reliance on familiar 'starter' stacks have reduced developer exploration and experimentation. The author argues that the ease of cloning existing repositories and prompting agents to build on top of known frameworks and databases has replaced the old cycle of discovering, imagining, and struggling with unfamiliar technologies. While acknowledging that shipping fast and using boring, proven technology is valuable, the piece calls for making room for inefficient, exploratory projects that may never ship but preserve the joy of learning something new.","url":"https://daily.dev/posts/data-right-next-to-your-code-8pszsmc0t","datePublished":"2026-08-13T09:12:23.191Z","dateModified":"2026-08-13T09:12:43.823Z","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0","description":"Senior Full-Stack Engineer. Indie builder shipping Docker Monitor and SaaS tools. ","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":7960}},"image":"https://media.daily.dev/image/upload/s--El4URaRm--/f_auto/v1786612344/posts/8PSzsMc0T?_a=BAMAMicg0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/emop47rpuw8dnjhp6r1b6","name":"Trevor Suna"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trevor Suna","item":"https://daily.dev/sources/emop47rpuw8dnjhp6r1b6"},{"@type":"ListItem","position":3,"name":"Data Right Next to Your Code"}]} ```