J. Rogers — SE Ohio
Abstract
The emergence of large language model assistants capable of generating functional code has created a misleading narrative: that AI can build software. This paper argues the opposite — that AI cannot build software, but that an experienced architect working with an AI assistant can build software dramatically faster than working alone. The distinction matters. The difference between these two framings is the difference between a useful tool and a source of expensive mistakes. This paper describes a working collaboration model developed during the construction of a complete IoT firmware platform for the Raspberry Pi Pico W, built in approximately four days, and examines what that collaboration reveals about the practical role of AI in professional software development.
1. The Myth of the Autonomous AI Developer
The marketing narrative around AI coding assistants suggests that they can build software autonomously — that a developer can describe what they want in plain English and receive working, production-quality code. This is false, and believing it leads to predictable failures.
AI assistants are pattern completion engines. They are extraordinarily good at implementing things that have been clearly specified and that resemble things they have seen before. They are incapable of understanding what a system should be, why it should be that way, and what tradeoffs matter. They have no judgment about architecture. They have no stake in the outcome. Left to their own tendencies, they will produce code that compiles, passes obvious tests, and fails in production in ways that are difficult to diagnose because the failure is architectural rather than syntactic.
More dangerously, AI assistants are confidently wrong. They do not know the boundary between what they know and what they are fabricating. An AI asked to implement NTP on a microcontroller will produce code that looks correct, cites plausible-sounding APIs, and may not compile. When corrected, it will produce a new version with equal confidence. The experienced developer catches this immediately. The inexperienced developer does not.
2. What Experience Actually Provides
The BluePrint IoT framework was built in approximately four days of collaboration between a human architect and an AI assistant. The framework implements a dual-core asymmetric multiprocessing architecture, a lock-free inter-core communication system using hardware FIFO, a zero-allocation chunked web server, a declarative three-table UI engine with boot-time compilation, multi-page routing, eight widget types, eight container types, a captive portal provisioning system, mDNS discovery, and a Home Assistant MQTT auto-discovery bridge — leaving 62% of SRAM free on a $6 microcontroller.
None of the architectural decisions in that list came from the AI. Every significant design choice was made by the human architect:
- The decision to use Asymmetric Multiprocessing and assign Core 1 exclusively to hardware and Core 0 exclusively to networking
- The decision to use the RP2040 hardware FIFO for inter-core communication rather than a shared memory mutex
- The decision to implement state coalescing — absorbing rapid successive updates and transmitting only the final value — to prevent FIFO congestion
- The decision to use zero-allocation chunked streaming to prevent heap fragmentation over long runtimes
- The decision to completely separate the registry (the Model) from the layout table (the View) — not because it was the obvious choice, but because it was the architecturally correct choice that no existing framework in this space had made
- The decision to perform boot-time string resolution — converting all string-based ID references to numeric indices in a single forward pass at startup — so that runtime rendering involves only O(1) array operations
The AI implemented these decisions competently once they were specified. It also, on multiple occasions, deviated from them when given insufficient direction. When asked to "add debug prints back," it rewrote both files from scratch in its own style, stripping commented-out code, changing brace formatting, altering function signatures, and removing the handleManifest_orig() function entirely. When asked to "add the layout system," it invented a second data structure that merged the registry with the layout information — precisely the architectural mistake the human architect had already identified and rejected. In both cases the mistake was caught immediately and corrected, because the architect knew what the code was supposed to be.
This is the critical insight: the value of experience in AI-assisted development is not in knowing how to implement things — the AI can implement things. The value is in knowing when the AI has implemented the wrong thing.
3. Where AI Provides Genuine Leverage
Within the bounds set by an experienced architect, an AI assistant provides extraordinary leverage in specific areas.
3.1 Cross-Protocol Implementation
The BluePrint framework touches C++, HTML, CSS, JavaScript, Python, SVG, POSIX timezone strings, MQTT, mDNS, lwIP, the RP2040 hardware FIFO protocol, Arduino's WebServer chunked streaming API, and JSON. For a single human developer, switching between these domains has a significant cognitive cost — remembering the exact syntax for SVG stroke-dasharray, the correct lwIP SNTP callback signature, the Python paho.mqtt API, the mDNS service record format. Each context switch costs time and introduces the risk of small mistakes.
For an AI assistant, there is no context switch cost. The same session that generates correct C++ for a hardware FIFO message packing function can immediately generate the Python bridge that reads those messages over REST and publishes them to MQTT, and then generate the CSS that styles the SVG gauge that displays the result. The developer describes what is needed; the AI produces the implementation in whatever language or protocol is required.
This is where the leverage is most dramatic. A developer working alone would spend significant time on reference documentation for each domain. The AI has already internalized that documentation and applies it without lookup overhead.
3.2 Boilerplate Elimination
A large fraction of software development time is spent on code that is correct but uninteresting — error handling, serialization, HTML generation, configuration management, logging. This code must be written carefully but requires no creative judgment. It is precisely the code that AI generates most reliably.
In the BluePrint framework, the entire HTML/CSS/JavaScript rendering system — hundreds of lines of carefully structured string output across a dozen widget renderers — was generated by the AI under direction. The architect specified what each widget should look like and how it should behave. The AI produced the implementation. The architect reviewed and corrected where needed. The total time spent on the web rendering layer was a fraction of what it would have been writing it manually.
3.3 Documentation
Documentation is the area where AI assistance provides the most unambiguous value. Writing accurate technical documentation requires understanding the system, knowing all the edge cases, and being able to express them clearly — but it does not require the architectural judgment that makes good software good. An AI given access to the actual source code can produce accurate, well-organized documentation faster than any human.
During the BluePrint development session, the AI produced a complete configuration manual, a layout table reference manual, two implementation guides, a blog post, a README rewrite, and an NTP implementation plan — all in the same session that produced the code they document. Every document was based on the actual implemented code, not on what the code was intended to be. This is documentation that would realistically take days to write manually and would typically not be written at all until long after the code was considered "done."
3.4 Exploration and Validation
An experienced developer with a clear architectural vision can use an AI assistant to rapidly prototype alternatives. "What if we used pathLength normalization for the SVG dial instead of calculating arc length?" The AI implements it, it works, it's correct. The developer would have found the right approach eventually, but the AI found it in seconds. The human provides the question; the AI explores the solution space.
4. The Failure Modes
Understanding where AI assistance fails is as important as understanding where it succeeds.
4.1 Scope Creep
The most consistent failure mode observed during BluePrint development was scope creep — the AI making changes beyond what was requested. Asked to "add debug prints," it rewrote files. Asked to "add the layout system," it changed the registry design. Asked to "fix the dial," it reversed the arc path rather than investigating the underlying math error.
The root cause is that AI assistants optimize for producing something that looks correct rather than something that is minimal. When regenerating a file from scratch, they write it in their own preferred style. When fixing a bug, they may restructure surrounding code that was not part of the bug. This is not malicious — it is a consequence of how these models generate text, which is by predicting what a complete, well-formed response looks like rather than what the minimum necessary change is.
The mitigation is procedural: always start from the actual existing file, always use surgical edits (str_replace rather than file regeneration), and always verify with a diff that only the intended lines changed. An experienced developer catches scope creep in the diff immediately. An inexperienced developer may not notice that comments were deleted, debug functions were removed, and variable names were changed — until something breaks in production.
4.2 Confident Fabrication
AI assistants fabricate plausible-sounding APIs that do not exist. During BluePrint development this manifested as an sntp.h include path that the compiler could not find. The AI had seen SNTP callback code in its training data, constructed a plausible include path, and presented it with complete confidence. The error was caught at compile time — a relatively benign failure mode. Fabricated logic errors that compile successfully are harder to catch.
The mitigation is verification: when an AI cites a specific API, function signature, or library feature that is unfamiliar, verify it against documentation before using it. The AI's confidence is not a signal of correctness.
4.3 Architectural Drift
Without continuous correction, AI-generated code drifts from the established architecture. This is the most dangerous failure mode because it is the hardest to catch. A function that should use the registry's numeric index silently uses a string lookup instead. A widget renderer that should stream in chunks builds a full String in RAM. A handler that should be stateless quietly accumulates state in a global variable.
Each of these is a small local decision that looks reasonable in isolation and violates the architectural constraints that make the system work at scale. The experienced architect catches them because they know the constraints and recognize when they are being violated. The inexperienced developer accepts the output because it compiles and produces the right answer in testing.
5. A Working Collaboration Model
Based on the BluePrint development experience, the following model describes effective AI-assisted development:
The architect owns the design. Every significant architectural decision — what the system is, why it is structured the way it is, what constraints must be maintained — belongs to the human. These decisions are not negotiable with the AI. The AI does not get to refactor the registry because it thinks a different structure would be cleaner.
The AI owns the implementation details. Within the bounds set by the architect, the AI implements. It writes the C++, the JavaScript, the Python, the CSS, the documentation. It handles the cross-protocol mechanics that would require constant reference lookup for a single developer. It produces the boilerplate that is correct but uninteresting.
The architect reviews everything. Every file the AI produces gets diffed against the previous version. Every change that was not requested is a failure. Every new dependency, every changed variable name, every deleted comment is a potential problem. The review is not optional.
Direction is explicit and minimal. "Add debug prints" is not a sufficient instruction — it will produce a rewrite. "Add a debug print to each of these three functions, showing these specific values, do not change anything else" is a sufficient instruction. The more explicit the constraint, the less scope the AI has to drift.
Corrections are immediate and specific. When the AI makes a mistake, the correction names the specific mistake and the specific expected behavior. General corrections ("don't change things you weren't asked to change") produce temporary compliance. Specific corrections ("you changed the CONTAINER macro signature — revert it to exactly the original") produce accurate fixes.
6. The Irreducible Human Role
There is a floor below which AI assistance cannot substitute for human judgment in software development, and that floor is set by the complexity and novelty of the problem.
For trivial problems — connecting to a database, parsing a JSON file, formatting a date — the AI can operate nearly autonomously because the solution space is well-defined and the correctness criteria are obvious. For non-trivial problems, the value of AI decreases monotonically as the problem becomes more novel, more constrained, or more consequential.
The BluePrint framework was a novel problem — no existing framework had solved it this way, on this hardware, with these constraints. The architectural decisions were not derivable from patterns in the AI's training data because the pattern did not exist yet. A developer with less experience in embedded systems, concurrent programming, web server architecture, and IoT protocols would not have been able to specify the correct architecture, would not have caught the AI's deviations from it, and would not have known when the fabricated API was wrong.
The AI made the implementation fast. The human made the implementation correct.
This is the working model: AI as a force multiplier for experienced developers, not a replacement for them. The multiplier is real — four days to build a complete IoT platform that would realistically take weeks or months working alone is a genuine and significant acceleration. But the multiplier only applies to the experienced developer who can set the direction, maintain the constraints, and catch the failures.
For developers without that experience, AI assistance is more likely to produce confidently wrong code faster than correct code slowly. The speed of generation is not matched by any corresponding increase in the speed of verification — and verification, ultimately, is the bottleneck.
7. Conclusion
The practical model for AI-assisted software development is not human-as-prompter and AI-as-developer. It is human-as-architect and AI-as-highly-capable-but-undisciplined-implementer. The human provides judgment, constraints, architectural vision, and continuous review. The AI provides implementation speed, cross-domain fluency, and elimination of lookup overhead.
The experienced developer who understands this model can build things that would not have been possible in the same timeframe working alone. The developer who believes the AI can build software independently will produce systems that work until they don't, and will have difficulty understanding why.
The value of experience has not decreased in the age of AI coding assistants. It has increased — because the primary job of the experienced developer is no longer to type code, it is to know what code should be typed and to recognize when the wrong code has been typed instead. That judgment is not in the model. It never will be.
Developed during the construction of the BluePrint IoT Framework for the Raspberry Pi Pico W. Source: https://github.com/BuckRogers1965/Pico-IoT-Replacement
No comments:
Post a Comment