Eric Koleda

@DustinRGood @DanielMiessler @trq212 🤞🏻

@DanielMiessler @trq212 This pack may have gotten more valuable it seems....@erickoleda coda.io/packs/rich-tex…

This is really cool thinking from @trq212 here, but I think I disagree with the solution. He makes a great point about Markdown being more difficult to share and communicate ideas with, because formatting and visuals can make things super easy to understand. My problem with the approach is that, by trading editabilty for readability, we’re separating we humans even further from the creation process. I value Markdown because I value text. And I value text because I see it as one step away from thought. I believe thinking is the one thing we should be careful not to outsource, and I worry what this idea smuggles in is a major step toward making our creations opaque to humans. Not just AI's creations, but ours as well. The reason I value Paul Graham so much is because of the idea compression work that goes into writing super clean prose. It's difficult to write clearly because it requires thinking clearly. Text makes your ideas naked, and I like that. - What is the problem, exactly? - What should we do to solve it? - Why is our solution better than alternatives? I love the challenge of crystalizing this kind of critical stuff in pure text before any technology is involved. If we're not writing that text ourselves, and then editing it, it starts to feel a lot like bringing a strong robot to the gym. I worry that if we vibe-think to AI and have it spit out amazing HTML, we're instantly disconnected from the idea. Like where did the idea go? It started as vibes and got put through a woodchipper and turned into someone else's HTML. Can I see it in 4 simple bullets? Can I stare at it? Can I grapple with it. Can I tweak it? It's an idea. I need to be able to wrestle with it. Of course we can ask the AI to summarize its brilliant HTML document into four bullets, but we'll have lost through compression and expansion some percentage of the original. Maybe I'm being overly emotional here. I just feel like if you didn't put the hard thinking and writing work into the original idea, and then maintain it in a format that's easy for humans to read and edit, then you have somehow surrendered something Holy to the machines. I say this as a total AI maximalist. But I get the point he's making, and I think it's super valid. It's hard to explain or convince people of things with a giant text file. Formatting massively helps. Images massively help. Even an interface or a video or something. So we're synched on that. I just think it might be better to come at the output we both want in a different way. - MARKDOWN: Easy for humans to write, hard for humans to read. - HTML: Hard for humans to write, easy for humans to read. Maybe the solution isn't moving the first step to HTML where it becomes more opaque to both agents and humans (plus the versioning issues Thariq talked about). Maybe the solution is something crazy like document pairing: like you have the thought file and you have the presentation file(s). The proposal is to ask AI to just write HTML, right? Well why not just have a separate but linked file for that? One is for crystal-clear human creation and sync between human and AI. Simplicity, clarity, precision, and human editability. And then AI can produce whatever from that. Images, diagrams, videos, or whatever. And if you want, yes, a full HTML file that contains all of them. And that can be what you use to present or share the idea with audiences. (Plus there's the fact that some file formats are literally directories, which could be shared with lots of related content, and then there's also things like .mdx that allow for richer content in Markdown, etc.) I hate the idea of multiple files, but I think it's far preferable to losing the transparent, editable connection to the idea that you get with text. Plus, the better and cheaper AI gets, the more trivial it will be to have the core thought file plus n-number of associated versions or formats that are useful for different audiences. Basically I think it's much easier for AI to make a rich and shareable version of clean, editable thought, in the form of text, than it is for humans to stay connected with ideas as opaque HTML. And I think the human thought-to-text connection is the most important thing to preserve. Still thinking it through, however, and massive thanks to @trq212 for the push for all of us to evolve on this.

@pamelafox I've been doing some demos with the Icons8 MCP server: icons8.com/mcp

Any favorite non-auth'd public MCP servers? Looking for more examples for a beginning MCP exercise. (Auth'd servers are more interesting, like GitHub MCP, but I always start with non-auth'd in tutorials)

"AI makes everyone a developer" is true the same way "cameras makes everyone a photographer"

A few weeks ago, I joined some of my Superhuman colleagues in Austin to help run a pop-up experience at SXSW. It was my first time at the conference (and in the city), and it was such a blast!

Every time we've made it easier to write software, we've ended up writing exponentially more of it. When high-level languages replaced assembly, programmers didn't write less code - they wrote orders of magnitude more, tackling problems that would have been economically impossible before. When frameworks abstracted away the plumbing, we didn't reduce our output - we built more ambitious applications. When cloud platforms eliminated infrastructure management, we didn't scale back - we spun up services for use cases that never would have justified a server room. @levie recently articulated why this pattern is about to repeat itself at a scale we haven't seen before, using Jevons Paradox as the frame. The argument resonates because it's playing out in real-time in our developer tools. The initial question everyone asks is "will this replace developers?" but just watch what actually happens. Teams that adopt these tools don't always shrink their engineering headcount - they expand their product surface area. The three-person startup that could only maintain one product now maintains four. The enterprise team that could only experiment with two approaches now tries seven. The constraint being removed isn't competence but it's the activation energy required to start something new. Think about that internal tool you've been putting off because "it would take someone two weeks and we can't spare anyone"? Now it takes three hours. That refactoring you've been deferring because the risk/reward math didn't work? The math just changed. This matters because software engineers are uniquely positioned to understand what's coming. We've seen this movie before, just in smaller domains. Every abstraction layer - from assembly to C to Python to frameworks to low-code - followed the same pattern. Each one was supposed to mean we'd need fewer developers. Each one instead enabled us to build more software. Here's the part that deserves more attention imo: the barrier being lowered isn't just about writing code faster. It's about the types of problems that become economically viable to solve with software. Think about all the internal tools that don't exist at your company. Not because no one thought of them, but because the ROI calculation never cleared the bar. The custom dashboard that would make one team 10% more efficient but would take a week to build. The data pipeline that would unlock insights but requires specialized knowledge. The integration that would smooth a workflow but touches three different systems. These aren't failing the cost-benefit analysis because the benefit is low - they're failing because the cost is high. Lower that cost by "10x", and suddenly you have an explosion of viable projects. This is exactly what's happening with AI-assisted development, and it's going to be more dramatic than previous transitions because we're making previously "impossible" work possible. The second-order effects get really interesting when you consider that every new tool creates demand for more tools. When we made it easier to build web applications, we didn't just get more web applications - we got an entire ecosystem of monitoring tools, deployment platforms, debugging tools, and testing frameworks. Each of these spawned their own ecosystems. The compounding effect is nonlinear. Now apply this logic to every domain where we're lowering the barrier to entry. Every new capability unlocked creates demand for supporting capabilities. Every workflow that becomes tractable creates demand for adjacent workflows. The surface area of what's economically viable expands in all directions. For engineers specifically, this changes the calculus of what we choose to work on. Right now, we're trained to be incredibly selective about what we build because our time is the scarce resource. But when the cost of building drops dramatically, the limiting factor becomes imagination, "taste" and judgment, not implementation capacity. The skill shifts from "what can I build given my constraints?" to "what should we build given that constraints have in some ways been evaporated?" The meta-point here is that we keep making the same prediction error. Every time we make something more efficient, we predict it will mean less of that thing. But efficiency improvements don't reduce demand - they reveal latent demand that was previously uneconomic to address. Coal. Computing. Cloud infrastructure. And now, knowledge work. The pattern is so consistent that the burden of proof should shift. Instead of asking "will AI agents reduce the need for human knowledge workers?" we should be asking "what orders of magnitude increase in knowledge work output are we about to see?" For software engineers it's the same transition we've navigated successfully several times already. The developers who thrived weren't the ones who resisted higher-level abstractions; they were the ones who used those abstractions to build more ambitious systems. The same logic applies now, just at a larger scale. The real question is whether we're prepared for a world where the bottleneck shifts from "can we build this?" to "should we build this?" That's a fundamentally different problem space, and it requires fundamentally different skills. We're about to find out what happens when the cost of knowledge work drops by an order of magnitude. History suggests we (perhaps) won't do less work - we'll discover we've been massively under-investing in knowledge work because it was too expensive to do all the things that were actually worth doing. The paradox isn't that efficiency creates abundance. The paradox is that we keep being surprised by it.

@GergelyOrosz The big disconnect (which existed pre-COVID too) is in-office mandates and distributed teams. Commuting to an office to spend all day in Zoom meetings is the worst of both worlds. A commitment to in-person work requires some hard decisions around team defragmentation.

Interesting how the industry is slowly reverting to pre-COVID. Still a flexible place to work as a dev (aka the odd work come in late home when waiting on an important delivery the morning / leave early when needed) - but full-remote work the minority across the industry Wix:

Are your @coda_hq docs getting too big? Receive an error message about your doc size? We can help We run a streamlined and dedicated Doc Audit service to get your docs back up and running fast! Shoot me a DM or email- info@simpladocs.com and we'll get you in good shape!

Going live with @fharper in 3 minutes! youtube.com/watch?v=slkCXo…

Join me and my guest @erickoleda, Lead Developer Relations at @Grammarly exceptionally Tuesday at 3PM ET, while we discuss all things developer relations, and learn more about building a Pack, an extension to your Coda documentation. youtube.com/watch?v=slkCXo…

I don’t care if you do JavaScript or not, or if you use Bun or not, I think this article by @lydiahallie is absolutely a must-read for every developer. It’ll change the way you think about building performant systems. It’s on my top 10 dev articles. bun.com/blog/behind-th…

With MCP tools, is there any expectation of backwards compatibility? For traditional APIs making breaking changes in a big deal, but is an MCP client to assume that the list of tools and/or shape of them can change at any time without warning?

@TomFrankly @NotionHQ I've fallen into that same trap many times, typically when filing a bug.

Why I take forever on videos: In a script, I write, "This trick works with all of these @NotionHQ block types..." Then I think, "Wait, is that always true?" 2 hours later, I've tested things no one else will ever try and submitted 3 bug reports... instead of writing the video.

Honored to be a part of a panel talk at the Oktane conference in a few weeks, on the topic of Cross App Access (XAA). I'll be on stage with @aaronpk, the OG of OAuth, and great minds from Okta and Box. Register to join live or watch online, click here ➡️ bit.ly/3JxtPHy

@mjackson The alternative would be an implicit await I guess? The danger there is some lower function introduces some async behavior, slowing down everything else above it. The pain of the async contagion is helpful, at discouraging dependencies from sneaking in delay.

Async code in JavaScript is contagious. Any time you define an async function, the caller must also be async. async function fn() { // ... } async function mustAlsoBeAsync() { let result = await fn() // ... } 1/?

I'll be back at @devrelcon NYC this July, and I'm looking forward to giving my first lightning talk there! I'm oddly passionate about bug reports, and I'm looking forward to sharing my tips, tricks, and enthusiasm with fellow DevRel folks. nyc.devrelcon.dev/sessions/2508

My two tips for API change management: 1) Never make breaking changes 2) Constantly make breaking changes I (try to) make that make sense in the talk I gave at @apidays NYC 2025, and you can watch a pre-recorded version of that talk here: youtube.com/watch?v=Kvtrp6…

At a session about OAuth2 at #apidaysNYC, living my best life.

Just dropped my latest @coda_hq pack: Global Postal & Geologic PRO! 🌍📍 It brings real-time city, country, timezone, currency, and more info right into your docs from addresses or coordinates, based on the @OpenCage API ⤵️ @huizer/published-1-dollar-coda-packs-by-christiaan/global-postal-geologic-pro-48" target="_blank" rel="nofollow noopener">coda.io/@huizer/publis…

@Erwin_AI Ya, it's not clear to me what an MCP server provides that a Swagger/OpenAPI spec does not or can not.

I still don't get why MCP exists and what it does differently than having an API. Yes, it's built "for AI specifically" but AI is already capable of using APIs. And we have tons of good protocols/frameworks already. Srsly, I can't be the only one here thinking this?

Have you used @coda_hq's somewhat-secret Developer Mode? If so, we've made some minor improvements that should make it a bit more useful: community.coda.io/t/minor-improv…