From Zero to Production in a New Language in One Day

“You can’t rely on AI to write ‘proper’ production code” - or can you? I recently had to write my first Java service for production use, with zero prior Java experience and a week’s deadline. In the event, I delivered it in a day using AI acceleration. Since I’m not sure that I can share details of that project, I’m showing how I did it by recreating the same approach with a React app - from zero experience to in-production code in a single day. The running implementation is here and the code is here

Key Learning Points

A lot of software is not revolutionary and AI (LLM) acceleration can be a massive accelerator, here specifically in

• Converting/translating from one language to another
• Resolving syntax, conventions and basic implementations for common use cases
• Getting real world stuff done

However

• A keen eye/clear sense of what good looks like is needed to ensure sensible results and avoid getting into the weeds
• It’s important to have rigorous acceptance criteria. This was easy to establish with the previous Java case but I did not set any in detail for the React app.

The Background

I’m a big fan of using LLM ‘AI’ acceleration as endorsed by Simon Willison. When I am not working on a project I like to keep in shape with e.g. personal projects, coding katas or personal study. I recently wrote a series of small Python scripts to give information about a given day using native calculation and free APIs. Initially I was querying the weather for a given location and getting the weekday for a given date using Zeller’s Congruence.

I thought it would be nice to be able to show this off but the distribution options didn’t seem very appealing:

• Generic Github repository - I wouldn’t really expect anyone to download toy-level python scripts and run them. If they are able to get that far then they probably have better options.
• Host on Lambda - command-line apps would not be very visually appealing and would involve some networking and frontend work
• Host on some sort of container platform. I have explored this previously and it isn’t cheap to keep an instance running to host. Yes there is AWS AppRunner, Google CloudRun etc. but this wouldn’t address visual appeal…

Ideally I would have this somehow integrated within my Website.

Starting Small

I asked Claude about the options for having information about a day in history and initially it gave me a React component for ‘Chronicling America API’. React/Next.js looked like a great opportunity to try something with a new frontend language/framework. I had no prior experience with it but I had a clear idea of what I wanted to achieve and where I needed it to fit. Unfortunately the suggested API runs only up to 1963 which isn’t much good for many people to query, e.g. the day they were born, so I asked about Wikipedia and got an updated component. I did need to then request a date picker but the suggested implementation didn’t seem too shabby to start with.

The initial suggested build process and linting was broken and took a bit of interactive debugging but once arrived at a local build I was able to get summary build instructions covered in a Readme.

Building a Bit Bigger

I asked Claude about the options to include a weather widget based on the Python code I already had to query open-meteo and calculate historic days of the week. Modern Javascript could do its own date calculation but I specifically wanted to leverage the translated code. Here, as previously, it helps a great deal to have a clear idea of the goal- I had a clear idea of the API I wanted to use, which data attributes, and how I would like the text information formatted. Open-Meteo themselves provide sample code with a configurator for Python, Typescript, and Swift. I was also doing some formatting and simple conversions, e.g. giving a compass direction for wind rather than degrees, and giving km/h/mph conversions simply because I felt that this was more relatable. Of course this did not include graphical elements at this point.

Here Claude was admirable, not just for providing equivalent code in translation but also a basic directory/file structure for the multi-component application- later extended and refined.

Pretty soon I had something running locally and could move onto refining the user experience.

Refining the User Experience

I had to specifically ask to have the date input once and inherited for each component and I had to reiterate that I wanted all of the same attributes and customisations as my provided Python code output.

I also found an off-by-1 issue with the React implementation provided for Zeller’s congruence due to an incorrect UTC conversion. This was only apparent because Claude had wanted to display both the ‘original’ and the ‘target’ day despite the fact that they should be identical… Once I had this sorted I updated to show only the single date. There were further minor regressions like line breaks disappearing which again were not too tough to fix.

I moved on to implementing a list of major world cities and locations. This is one thing that AI assistants can be great for - a whole bunch of boilerplate, here an array of cities with their latitudes and longitudes based on a one line prompt. This was especially useful here since my application and display code were intermingled.

Although Claude suggested a globe widget, I did not see the point- it seemed overly complicated and either too small to usefully show a location on world map globe, or else so big that it took over. I decided to have just a simple weather icon, e.g. with a little outline of a cloud. Claude rapidly obliged this request without my needing to trawl through traditional search engines and developer forums trying to find a suitable and supported widget library.

There were again linting issues and compile errors based on things like apostrophes. Some of Claude’s suggestions were confusing but I was able to get these clarified and resolved, e.g. by requesting complete corrected files where practical.

Framework-Specific Challenges

I ran into some errors specific to React but which I could quickly explore and fix with AI assistance.

I had difficulty getting a working date selector - this was initially a free text field expecting a specific format and then validating in sequence but the react code evaluated continuously, which meant that it was not possible to type in a date - because a 1 digit date was by definition invalid and further input prevented. I initially split out to drop-downs for day and month but this issue persisted and recurred with the year. Because I had not implemented a ‘full’ version of Zeller’s congruence I had to restrict to dates after 1753 (later fixed - see the update below). In the solution eventually arrived at, the validation rules would not be applied for the year field until 4 characters had been input, thus circumventing premature lockout.

I also encountered React hydration errors - a common challenge when server-side rendered content doesn’t match what React expects to render on the client side. These typically occur when components render differently based on client-specific information (like browser theme or screen size). While these errors would be familiar to experienced React developers, they were new territory for me. Some errors were critical and needed fixing - like inconsistencies in date formatting between server and client. Others were purely cosmetic and could be safely suppressed from display.

The next challenge involved working with Tailwindcss, a utility-first CSS framework that provides pre-built classes for styling. While powerful, theming each component individually proved extremely verbose - each UI element needed separate style definitions for both light and dark modes. I explored centralizing these theme definitions in a shared component, but this approach still required maintaining two theme variations for each CSS class. While some developers might prefer extracting these definitions into separate theme files, I found that directly using Tailwindcss’s utility classes made the code more immediately understandable, even if more verbose. It was annoying to have to manage each component theme individually but from research with Tailwindcss it seems that this is ‘normal’ practice.

Conclusion

I’m pleased with the result here - I was able to develop a multi-module application in a foreign (to me) language, get it built and integrated inside a day using AI/LLM assistance, a keen eye, some critical thought and a clear vision. It’s by no means a revolutionary achievement in software and I am sure a React expert could recommend better, or at least different, ways of doing what I did here but it works and it fits into the space required - here running code client side served from a static website. In this respect this project is very much like the Java project I described earlier- that too was essentially turnkey functionality but again with some very specific requirements about the (foreign to me) language and the space it needed to fit into. In neither case was a local human domain expert available. I think that this is a strong counter to AI naysayers who claim that ‘AI can’t write code’- whilst technically true, it misses the point. No, you can’t just dump a requirement and expect a working implementation but with sensible engagement you can make rapid progress. I feel that the same approach that worked for me with Java and React could be used with any popular framework or language- having a clear vision of what’s needed, using AI to accelerate the basic implementation, and applying critical thinking and knowledge from comparable/equivalent implementations to validate and refine the results.

Refactor August 2026

I was unhappy with the limitations and with the choice of Tailwind.css at the time but since I have this application on my website with source code available I decided to refactor:

Date handling

• Removed the 1753/1754 floor on the date picker mentioned above - any year from 1 onward is now accepted
• Replaced Zeller’s Congruence with a Julian Day Number calculation, using the Julian calendar before 15 October 1582 and the Gregorian calendar from then on, so weekdays are correct across the calendar reform rather than just for the modern era
• Added a note for dates in the British calendar gap (3-13 September 1752), which never appeared on a British calendar when 11 days were dropped switching from Julian to Gregorian
• Fixed a native JavaScript Date bug where two-digit years (0-99) were silently remapped to 1900+year
• Weather data is only ever available from 1940 onward (Open-Meteo’s real archive floor) - this now shows a clear “unavailable” message instead of a confusing upstream API error

Tooling

• Switched package manager from npm to bun
• Upgraded Next.js, ESLint, TypeScript and other dependencies to latest, deliberately keeping TypeScript and ESLint one major version back where their surrounding toolchain (typescript-eslint, eslint-plugin-react) hasn’t caught up yet
• Replaced the legacy next lint command, removed entirely from the Next.js 16 CLI, with running ESLint directly

Styling

• Replaced Tailwind CSS with CSS Modules
• Fixed the Geist font, which had been loaded via next/font/google since the original build but never actually wired up to any CSS - it had been rendering in plain Arial the whole time
• Raised the minimum font size app-wide to 1rem