loading . . . What coding with AI feels like now <h2 id="notes-from-the-edge-of-building-with-llms">Notes from the edge of building with LLMs</h2><p>I am all in on large language models as cognitive amplifiers. I use them to think, to structure, to explore, to write. That part feels natural to me. What I have never been particularly drawn to is using them as coding tools. Programming has always felt like a different craft. Adjacent, interesting, but not where I naturally place my attention.</p><p>And yet, over the past months, that boundary has become harder to ignore. Not because I suddenly wanted to become a developer, but because clients started asking different questions. They see headlines about âAI eating codeâ. They see demos racing past on LinkedIn. And they wonder whether they are missing something important.</p><p>So I decided to explore. Not to reskill, but to orient myself. To understand what is actually changing, where agency now sits, and what is realistically accessible to people who are curious, but not intent on becoming software engineers.</p><p>What follows is not a survey. It is a short field note, guided by my own steps.</p><h2 id="standing-near-the-edge-of-coding">Standing near the edge of coding</h2><p>I have never really been a coder. I know enough to follow along, to collaborate, to get something running from <a href="https://github.com/rhoeijmakers">GitHub</a> if I have to, but it has always felt like a different craft. Interesting, sometimes impressive, but not where I naturally operate. You may recognise that position. Curious, not allergic to technology, but not inclined to disappear into documentation or frameworks either.</p><p>What surprised me in these experiments was not how powerful the tools were, but how quietly the boundary shifted. Not because I learned a new skill, but because the effort moved. An idea could turn into something that actually works. Not a mock-up, not a diagram, but a usable thing.</p><p>That was new to me. Not spectacular, but disorienting in a subtle way.</p><h2 id="first-encounter-describing-a-thing-into-existence">First encounter: describing a thing into existence</h2><p>The first thing I tried was <a href="https://lovable.dev">Lovable</a>.</p><p>Someone <a href="https://www.linkedin.com/posts/cassombroek_bij-de-meeste-bedrijven-zijn-e-mailhandtekeningen-activity-7418204193548562432-Gv62?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAGPccBqY4Rvlcj2zZ2PdvOk7tl5dQrkUs">shared a prompt</a> for building a simple email signature generator. I copied it, adjusted it slightly, and watched the result appear. A working interface. Inputs, preview, export. No setup, no explicit architectural decisions on my side.</p><p>What struck me was how familiar this felt. This was not programming in the traditional sense. It felt much closer to product definition. Describing behaviour, constraints, and outcomes. The kind of thinking that normally stops at wireframes or tickets.</p><p>Here, the description executed.</p><p>That is the strength of tools like this. They let you stay at the level of intent and outcome. At the same time, the trade-off is clear. Many decisions are made for you. Hosting, structure, deployment, all of that is implicit. You gain speed and clarity, but give up control.</p><p>For an experiment, that was exactly right.</p><figure class="kg-card kg-bookmark-card"><a class="kg-bookmark-container" href="https://brand-signature-scribe.lovable.app/"><div class="kg-bookmark-content"><div class="kg-bookmark-title">Lovable App</div><div class="kg-bookmark-description">Lovable Generated Project</div><div class="kg-bookmark-metadata"><img class="kg-bookmark-icon" src="https://hoeijmakers.net/content/images/icon/favicon-40.ico" alt="" /><span class="kg-bookmark-publisher">Lovable</span></div></div><div class="kg-bookmark-thumbnail"><img src="https://hoeijmakers.net/content/images/thumbnail/id-preview-7f5b0dcc--bb3425a8-ad34-420a-81f6-0c4ac8723ba9.lovable.app-1768640349762.png" alt="" /></div></a></figure><h2 id="a-step-deeper-intent-meets-a-project">A step deeper: intent meets a project</h2><p>Curiosity pulled me one layer down. I wanted to see what would happen if I stayed close to intent, but entered a recognisable software project.</p><p>I tried <a href="https://www.anthropic.com/engineering/claude-code-best-practices">Claude Code</a> and connected it to GitHub. This time, the result was not an abstract app, but a repository. Files, versions, commits. I used it to build a bespoke email signature generator inside Google Workspace, backed by a Google Sheet and implemented with Google Apps Script.</p><p>The experience changed in kind.</p><p>Claude Code did not âbuild an app for meâ. It helped me think through a project. What goes where. What changes when I adjust something. How to iterate, deploy, and improve. The LLM was no longer replacing structure. It was inhabiting it with me.</p><p>I also felt a boundary. Systematic software development, long-term maintenance, deeper architectural decisions, that still felt like a different craft. Not inaccessible, but distinct.</p><p>What mattered was that this boundary was now visible.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://hoeijmakers.net/content/images/2026/01/image.png" class="kg-image" alt="" loading="lazy" width="2000" height="1364" srcset="https://hoeijmakers.net/content/images/size/w600/2026/01/image.png 600w, https://hoeijmakers.net/content/images/size/w1000/2026/01/image.png 1000w, https://hoeijmakers.net/content/images/size/w1600/2026/01/image.png 1600w, https://hoeijmakers.net/content/images/size/w2400/2026/01/image.png 2400w" /><figcaption><span style="white-space:pre-wrap">The signature app in Google Workspace.</span></figcaption></figure><h2 id="what-people-mean-when-they-say-%E2%80%9Cide%E2%80%9D">What people mean when they say âIDEâ</h2><p>This is where the term âIDEâ often comes in. IDE stands for Integrated Development Environment, but that label tends to obscure more than it explains.</p><p>In practice, an IDE is the place where software lives while it is being made and maintained. It is where files are organised, changes are tracked, versions are compared, and decisions accumulate over time. Not just a text editor, but a working environment with memory.</p><p>A widely known example is <a href="https://code.visualstudio.com">Visual Studio Code</a>, used by many developers and familiar to a broader technical audience. What is changing now is not the existence of such environments, but their role.</p><p>With LLMs embedded, IDEs start to absorb more of the thinking, explanation, and iteration that used to happen outside them. They begin to look less like specialist tools and more like shared workspaces between human and system.</p><h2 id="three-ways-of-building-loosely-speaking">Three ways of building, loosely speaking</h2><p>Looking back, what helped me make sense of this was not taxonomy for its own sake, but orientation. Roughly speaking, I now see three modes people move between.</p><p>First, <strong>outcome-driven tools like Lovable</strong>, where you stay at the level of intent and receive a working artefact.</p><p>Second, <strong>artifact-centric assistance</strong>, where LLMs help you produce scripts, components, or configurations that you then integrate yourself.</p><p>Third, <strong>IDE-centred environments</strong>, where the LLM is embedded into the development workflow itself and develops a persistent understanding of a system over time. Tools such as <a href="https://cursor.com">Cursor</a> are often mentioned in this context, as are <a href="https://openai.com/codex/">Codex</a>-based systems from OpenAI.</p><p>These are not strict categories. They overlap and evolve. But they differ in one crucial respect: where your agency sits. At intent. At artefacts. Or at systems.</p><p>What has changed is that moving between these layers no longer requires a hard identity shift.</p><h2 id="a-signal-worth-paying-attention-to">A signal worth paying attention to</h2><p>This is also why it is telling to see Google presenting tools like <a href="https://antigravity.google">Antigravity</a> explicitly as a ânext-generation IDEâ. Even if such tools are still emerging, the framing itself matters.</p><p>It suggests that IDEs are no longer seen only as specialist developer tools, but as environments where complex work takes shape, especially when that work results in living systems rather than finished documents.</p><p>That matters even if you never plan to work there yourself.</p><figure class="kg-card kg-image-card"><img src="https://hoeijmakers.net/content/images/2026/01/image-1.png" class="kg-image" alt="" loading="lazy" width="2000" height="1159" srcset="https://hoeijmakers.net/content/images/size/w600/2026/01/image-1.png 600w, https://hoeijmakers.net/content/images/size/w1000/2026/01/image-1.png 1000w, https://hoeijmakers.net/content/images/size/w1600/2026/01/image-1.png 1600w, https://hoeijmakers.net/content/images/size/w2400/2026/01/image-1.png 2400w" /></figure><h2 id="abundance-noise-and-judgement">Abundance, noise, and judgement</h2><p>One effect of this shift deserves a little more attention. As software becomes easier to create and easier to discard, the market around it changes shape.</p><p>We move away from a relatively structured landscape, with high entry costs and clear thresholds, towards something more crowded and informal. A place with many small offerings, many claims, many tools competing for attention. At times, it starts to resemble a medina: lively, inventive, and full of possibility, but also noisy and disorienting.</p><p>In such an environment, the hard part is no longer building something. The hard part is knowing what needs to be built, what can be thrown away, and what deserves care, continuity, and quality.</p><p>Not every problem needs a robust system. Not every tool should live beyond its moment.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://hoeijmakers.net/content/images/2026/01/30626148-E457-4C58-836E-EEAE655E76B5_1_105_c.jpeg" class="kg-image" alt="" loading="lazy" width="1024" height="768" srcset="https://hoeijmakers.net/content/images/size/w600/2026/01/30626148-E457-4C58-836E-EEAE655E76B5_1_105_c.jpeg 600w, https://hoeijmakers.net/content/images/size/w1000/2026/01/30626148-E457-4C58-836E-EEAE655E76B5_1_105_c.jpeg 1000w, https://hoeijmakers.net/content/images/2026/01/30626148-E457-4C58-836E-EEAE655E76B5_1_105_c.jpeg 1024w" /><figcaption><span style="white-space:pre-wrap">Finding your way in buying or using software is changing. </span></figcaption></figure><h2 id="what-actually-gets-democratised">What actually gets democratised</h2><p>Software development is becoming more democratic. Not because coding no longer matters, but because much of the handwork no longer determines who gets to participate.</p><p>It is now relatively easy to spin something up. To test an idea. To build a situational tool and discard it again. Software starts to behave more like a medium than a monument.</p><p>At the same time, this does not remove the hard parts. Vision still matters. Knowing what to build, for whom, and why does not get automated away. Nor does the work of building systems that are robust, scalable, secure, and efficient.</p><p>If anything, that work becomes more valuable.</p><p>Good developers do not become less important here. They become more important. Not because they type faster, but because they understand structure, trade-offs, and long-term consequences. The same goes for people who know how to deploy systems into production, test them properly, and keep them running once they stop being experiments.</p><p>What changes is the division of labour. A large amount of manual work has quietly been absorbed by tools. That opens space for non-coders to explore, and for coders to focus on what actually requires judgement.</p><p>So when people say âyou no longer need codersâ, they are pointing at the wrong thing. What is disappearing is not the craft, but the gatekeeping.</p><p>And in a noisier, more abundant landscape, that kind of discernment becomes the real advantage.</p><hr /><figure class="kg-card kg-bookmark-card"><a class="kg-bookmark-container" href="https://hoeijmakers.net/excel-and-the-future-cockpit-of-business-logic/"><div class="kg-bookmark-content"><div class="kg-bookmark-title">Excel and the future cockpit of business logic</div><div class="kg-bookmark-description">Excel has always been more than a spreadsheet. For decades it has been the place where business logic quietly lives. Not in software systems designed for control, but in the free space where analysts, planners and managers actually think. What interests me today is how this space is changing as</div><div class="kg-bookmark-metadata"><img class="kg-bookmark-icon" src="https://hoeijmakers.net/content/images/icon/Circle-logo-2-503.png" alt="" /><span class="kg-bookmark-author">Rob Hoeijmakers</span><span class="kg-bookmark-publisher">Rob Hoeijmakers</span></div></div><div class="kg-bookmark-thumbnail"><img src="https://hoeijmakers.net/content/images/thumbnail/IMG_5794-2.jpeg" alt="" /></div></a></figure><figure class="kg-card kg-bookmark-card"><a class="kg-bookmark-container" href="https://www.forbes.com/sites/joemckendrick/2026/01/15/smaller-nimbler-smarter-ai-taking-paths-of-least-resistance/"><div class="kg-bookmark-content"><div class="kg-bookmark-title">Smaller, Nimbler, Smarter: AI Taking Paths Of Least Resistance</div><div class="kg-bookmark-description">With AI projects this year, there will be less of a push to boil the ocean, and instead more of a laser-like focus on smaller, more manageable projects.</div><div class="kg-bookmark-metadata"><img class="kg-bookmark-icon" src="https://hoeijmakers.net/content/images/icon/144X144-F.png" alt="" /><span class="kg-bookmark-author">Forbes</span><span class="kg-bookmark-publisher">Joe McKendrick</span></div></div><div class="kg-bookmark-thumbnail"><img src="https://hoeijmakers.net/content/images/thumbnail/0x0.jpg" alt="" /></div></a></figure><figure class="kg-card kg-bookmark-card"><a class="kg-bookmark-container" href="https://hoeijmakers.net/excel-hidden-operating-system-of-business-reasoning/"><div class="kg-bookmark-content"><div class="kg-bookmark-title">Excel, the Hidden Operating System of Business Reasoning</div><div class="kg-bookmark-description">Excel has long been the silent operating system of business reasoning. AI may be about to extend that logic into natural language.</div><div class="kg-bookmark-metadata"><img class="kg-bookmark-icon" src="https://hoeijmakers.net/content/images/icon/Circle-logo-2-504.png" alt="" /><span class="kg-bookmark-author">Rob Hoeijmakers</span><span class="kg-bookmark-publisher">Rob Hoeijmakers</span></div></div><div class="kg-bookmark-thumbnail"><img src="https://hoeijmakers.net/content/images/thumbnail/IMG_8930-1.jpeg" alt="" /></div></a></figure> https://hoeijmakers.net/what-coding-with-ai-feels-like-now/
