Something Not-So-Simple This Way Comes

Software packages service [1] and it evolves from a conversation with the customer [2]. AI increasingly serves as an amanuensis in planning and execution. But it is conversation with real people, customers, that interactively learns requirements and matures a minimum viable product into a reliable tool.

Our "ICAL to CSV Converter" application predates coding AIs, making its evolution a case-study in the limitations and benefits of coding AIs in developing tools for people. Starting with our own need to convert ICS into CSV data we later put it in the Microsoft Store. In a process as old as trade, people taught us what to improve.

Our latest relaunch of "ICAL to CSV Converter" certainly benefited from AI coding from a specification. But the specification meant novel conversations with our users. Conversations that AI cannot undertake as they require genuine empathy with customers and taste [3]. Yes, watching telemetry for UI friction will highlight problems but unless someone has solved a similar problem before, AI will not arrive at a good solution.

Developers need to be aware of evolving specifications. As always, that means developers need to understand what is possible, and that still means reading the documentation.

Circular Documentation

An early post here noted that documentation and architectures had become less like engineering and increasingly resembled spellcasting [4]. The opacity of the documentation was not improved by its tendency to invoke novel terminology-known or defined elsewhere. One could easily spend hours reviewing content that led you back to your original reference in a fruitless search for concrete definitions.

Historically my projects would start with a survey of how others had solved similar problems. Very quickly, ideas (guesses really) would accumulate as to the techniques and suitable tools. Through a process of reading posts by other developers and documents associated with similar tools, I would get a good idea of what I needed to learn. This stage could last a few hours to weeks depending on the scale and risk of the project.

Then the learning and software spikes would begin. Learning involved reading all the documentation for all the tools. Reading everything was a necessary derisking step to develop intuition for what was possible and good. Often I have avoided expensive and frustrating mistakes by discovering some obscure cautionary note tucked in some obscure corner of volumes of documentation. Frequently, it would be hard to even find the note again.

Seems Harder – But Isn't

Integrating AI into this process has happened in stages but at first it wasn't very reliable, and my prompting wasn't skilled. Initially I used AI to brainstorm a few ideas and when I was frustrated by a project's poorly defined term.

But now my project effort looks more like this diagram:

Discovery > Understanding > Automation

Initial project planning involves collecting speculations about a problem, loose market description, informal thoughts about customer needs, and a lightly presented list of preexisting constraints. This is all tossed into an AI prompt in the role of unbiased expert. And a series of questions are asked. First, and this is vital - is there a need? Then, what does it look like? (market size, customers, and competitors) and you must cite sources. Once that is settled then have AI suggest three ways to address this market (I find asking for several solutions forces AI to prioritize them as: good, possible, and difficult). Getting these two things– market and tooling– to match is so important to get right that one must challenge the AI ferociously and iterate several times. Do this right and you are likely to meet a need. With a little luck you'll make a profit.

Don't Skip This

It is so tempting to just invoke AI and get vibe coding [5]. After all, you have done a lot of work understanding the need, choosing the tools, and developing a specification for a minimum viable product. Prompt the AI correctly and stand back – right?

Maybe someday, but not yet. More likely you will get a non-functional ball of code or architecture that you don't even understand well enough to prompt your way to a solution. Even though you might not code much, or at all, you are still needed to understand when something was missed. That means understanding the tools, and that means going back to the documentation. But this time AI removes frustrations at many levels. You can ask for the correct overview document. If the document assumes knowledge or uses terms you don't know, you can ask AI for working definitions. In fact, I often have two AI dialogs open as I utilize documentation: 1. my phone in voice mode defines unfamiliar terms as encountered and 2. a chat window taking notes and providing commentary on what I am reading. Having never to context switch in a search for answers speeds my document ingestion. As a non-expert, this is how you quickly develop enough experience to do the hardest part of the project: helping AI avoid blind spots.

It's Still Work

I have tried launching straight into vibe coding, armed with my spec, hoping to pick up knowledge as I encountered errors and directed AI to find them. This just hobbles the AI which with more capability, good unit tests, and completion criteria, can increasingly get a half-decent solution on its own. If you don't believe this, then at least you suspect it having seen the writing on the wall [6]. Week-by-week this seems inevitable.

So why take the time to understand the tools and their documentation? Only you know how to impress your human customers and reach them with empathy. You have seen the 'vibe coding' web pages that 'just work' [5]. But honestly, they look just plain average which is what basic prompting will get you. Your customers are not going to pay for average.

"That can be fixed with better prompting" you say? Yes, certainly, you will be coding more detailed prompts to effect the changes. But just because you can ask for something doesn't mean it is reasonable, possible, or what your customer wants.

Take as an example, "ICAL to CSV Converter", which has been under active development for years. This application converts ICAL (ICS) files into CSV files and back again. If there is a niche business, this is it. You would think that converting data between formats could be completely specified and straightforward. And yet, there are issues everywhere. Just today a colleague and I uncovered a new issue in our very niche product. When it is a new problem, and the answer is only in your customer's head; AI will not help you.

Human Quality

Relaunching our "ICAL to CSV Converter" application for Windows 10 has been a massive undertaking. This is now by far and without a doubt the best way to convert calendar ICS files to the popular but informal structured-data format of CSV files. Most of the challenge was in matching customer expectations to the informality of the CSV format.

"How can that be?" you say? "I load, use, and write CSV files all the time." And when you do, your application, probably Excel, applies its own definition. RFC 4180 is the post-hoc CSV standard, but applications seem frequently to diverge from that standard. For example, LibreOffice Calc and Excel can in some cases produce mutually incompatible CSV files [7]. Even the formally specified ICS format has applications that produce mutually incompatible content.

Applications working with similar data have diverging formats that can expect more trouble converting between the first's formality and the second's conventions. An intuitive and still correct "ICAL to CSV Converter" therefore has surprisingly many challenges. Take time zone handling, ICS files follow the IANA date format, while no fixed convention exists in CSV files.

Consider the acid test in data conversion, being able to preserve data in a round trip back to its original format. "ICAL to CSV Converter" can both convert from ICS to CSV and has another module that converts from CSV to ICS formats. An obvious test is, "can you convert ICS to CSV and then back to ICS?" Simple, if your starting ICS file matches your final ICS file then good – you pass! Indeed, moving from a well-defined format and back to an informal format is relatively easy. The loose time zone specification in CSV can be extended to represent the ICS IANA date format. It is mostly straightforward if you are careful of the special case around Zulu (UTC) time! However, a round-trip from CSV to ICS and back to CSV means accepting that not all CSV data will survive the transformation.

In this case, how do you handle a CSV datetime with no time zone specified when ICS requires time zones?

Human Control

Choices like this require a human to adjudicate correctly. Only humans have the real-world model that allows them to make the many special discoveries that enterprises knit together to create value. To date these enterprise discoveries have resided inside the minds of your most senior staff who know what problem necessitated a given choice. Software has always been a conversation with customers, in the case of enterprise software this conversation includes lessons learned from the past.

As AI takes ownership of software itself, enterprises will have to encode their institutional knowledge in the enterprise's software documentation. Software will be in "Loop 1" [8] where AI delivers software-satisfying documented specifications and tests. Documentation will become a "Loop 2" conversation between AI and human administrators [9]. There will even be a need for a high-level, "constitutional," "Loop 3" [10] where direction and guidance are beyond the reach of AI and entirely owned by humans.

AI can read the software, it can read your spec, but it will always be the role of humans to speak for humans as to why something needs doing.

---

References

1. Eric S. Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (Sebastopol, CA: O'Reilly Media, 1999). Specifically the quote: "software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry."
   Source URL: https://www.goodreads.com/author/quotes/18542.Eric_S_Raymond
   Notes: Raymond's classic open-source manifesto argues forcefully that software's real value is in ongoing service, not in shipping bits. The relevant passage appears in the "Magic Cauldron" section of the book. This is a well-known, widely cited work in the software industry.
2. Alistair Cockburn, Agile Software Development: The Cooperative Game, 2nd ed. (Boston: Addison-Wesley, 2007). Cockburn, a signatory of the Agile Manifesto, defines software development as "a cooperative game of invention and communication." His framework emphasizes that requirements emerge through ongoing dialogue with customers rather than being fully specified upfront.
   Source URL: https://www.goodreads.com/book/show/942577
3. Nate B. Jones, "The Universal AI Skill: Good Taste," AI News & Strategy Daily (YouTube), September 13, 2025. In this 15-minute video, Jones argues that "taste" — the accumulated intuition about what constitutes quality — is the essential human skill in the AI age. He defines taste as "the sense inside of you that something is right or something is wrong… where you start to accumulate enough experience in a particular area that you begin to have strong opinions."
   Source URL: https://www.youtube.com/watch?v=A_Lv0Ze272g
4. Joel Spolsky, "The Law of Leaky Abstractions," Joel on Software (blog), November 11, 2002. Spolsky argues that all non-trivial abstractions are leaky, meaning developers must understand the underlying systems beneath the abstractions they use. This creates a learning burden where "the abstractions save us time working, but they don't save us time learning." Documentation for complex systems often assumes familiarity with underlying concepts, creating circular knowledge dependencies where understanding one abstraction requires knowledge of what it obscures. The result is that modern developers must master multiple layers of complexity—each with its own opaque terminology and conventions—making programming paradoxically harder despite better tools.
   Source URL: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
   Notes: Spolsky discusses documentation that "invoke[s] novel terminology-known or defined elsewhere" and how "one could easily spend hours reviewing content that led you back to your original reference in a fruitless search for concrete definitions." While Spolsky doesn't use the "spellcasting" metaphor specifically, his post establishes how technical abstractions and their documentation create opacity that requires deep, circular learning of interconnected concepts.
5. Andrej Karpathy (@karpathy), post on X (formerly Twitter), February 2, 2025: "There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
   Source URL: https://x.com/karpathy/status/1886192184808149383
6. Simon Willison, "Software Factory," simonwillison.net (blog), February 7, 2026.
   Source URL: https://simonwillison.net/2026/Feb/7/software-factory/
7. ChatGPT conversation, "LibreOffice Calc and Excel can in some cases produce mutually incompatible CSV files."
   Source URL: https://chatgpt.com/s/t_6996507ba5e881919fe3782b903c6148
8. Gene Kim and Steve Yegge, Vibe Coding (Portland, OR: IT Revolution Press, 2025). As summarized in: IT Revolution, "The Three Developer Loops: A New Framework for AI-Assisted Coding," IT Revolution (blog), October 20, 2025. Kim and Yegge define three development loops: the Inner Loop (seconds to minutes — rapid AI-assisted code generation and verification), the Middle Loop (hours to days — coordination and workflow), and the Outer Loop (weeks to months — architecture and governance). "Loop 1" in the blog post corresponds to their Inner Loop, where the AI generates code satisfying specifications and tests in a tight feedback cycle.
   Source URL: https://itrevolution.com/articles/the-three-developer-loops-a-new-framework-for-ai-assisted-coding/
9. Gene Kim and Steve Yegge, Vibe Coding (Portland, OR: IT Revolution Press, 2025). The Middle/Outer Loop in Kim and Yegge's framework involves human oversight of architectural decisions, documentation governance, and the strategic conversation between development teams (increasingly AI-assisted) and human administrators who maintain institutional knowledge and architectural intent.
   Source URL: https://itrevolution.com/articles/the-three-developer-loops-a-new-framework-for-ai-assisted-coding/
10. Dario Amodei, interview by Dwarkesh Patel, "Dario Amodei — 'We are near the end of the exponential,'" Dwarkesh Podcast, February 13, 2026. In this interview, Amodei describes three sizes of governance loops for AI systems: 1. Loop 1: Within a single AI company (internal constitutional principles) 2. Loop 2: Across companies — different organizations putting out different constitutions that people can compare 3. Loop 3: Society at large — representative governments and the broader public having input on AI governance. Amodei states he'd like representative governments to have input, but notes that "the legislative process is too slow, therefore we should be careful." This maps directly to the blog's concept of a high-level "constitutional" loop where human direction and guidance are beyond the reach of AI.
    Source URL: https://www.dwarkesh.com/p/dario-amodei-2