[kcdc 2025] Crisis Coding: Navigating Impossible Deadlines

Speaker: Drew Spencer

For more see the table of contents


Background

  • Works at a lab (MAWD Pathology Group)
  • COVID created imposible deadlines

Situation

  • Dealing with a global crisis
  • Everything needed to be done as soon as humanly possible
  • Deadline was as soon as possible before legacy software died
  • Big labs couldn’t handle volume.
  • Repurposed instruments and tried to scale up.
  • Database started failing
  • Needed more flexibility, wanted to develop own because unique needs
  • Off the shelf solution would have taken a year

True Deadlines

  • Some are arbitrary deadlines and some are true deadlines
  • ex: launch date for funding

Requirements

  • Scalable
  • Google cloud

Lesson: Deliver what you can, when you can

  • Deliver most critical items ASAP
  • Delivered first thing in 100 days. MVP was a single test
  • Two week sprints
  • Do not deviate from spring cadence to bring in new requirements unless you have to
  • Work closely with key users
  • Guard vigilantly against scope creep
  • Protect developers from themselves- “it’s not that much effort to do x”
  • User noted only one instrument for test. Don’t spend time/lose trust demoing something that wasn’t critical
  • Intellectual debt is better than a failed project – ex: hard coding things

Lesson: Things will go wrong; react accordingly

  • Move fast and break things. But understand what cannot break.
  • Went live on a Saturday because volume was lower
  • Ran with a test patient – Mickey Mouse
  • Were sending results by fax. Line was busy after first one. Learned need to queue and send out in batches every 30 minutes. Fixed by Monday
  • Things will go wrong; it’s not always your fault. User entered wife’s phone number and use was looking at his phone. User errors hard to account for

Lesson: Trust

  • Trust team – no junior developers because needed to know team could deliver
  • Continue to deliver – incremental delivery
  • Build trust with leadership and clients
  • Trust must be from the top down.

Result

  • Over 900K Covid tests
  • Mass test sites in KC area
  • Platform for schools and businesses

Other notes from end and Q&A

  • While there wasn’t a defined, there was testing fatigue and a drop off in quantify
  • Max 5K tests in a day
  • Crisis pace not sustainable; crisis must end
  • Burnout
  • Everyone was exhausted but people expected it as normal. Need to get out of crisis mode. Use that pace selectively.
  • Had two systems. Just did Covid tests in new system. Used legacy system for everything else. Reporting from both systems
  • Tried to keep 8 hour workdays as much as can, although more when close to deadline. Did work weekends. Tried to guard teams time with nighttime calls and only let thru when system down.
  • Pre-covid everyone worked on site. Developers were almost all remote (not local)
  • Drove tester crazy. Short deadline to test but quality still matters
  • Deployed a week after sprint ended
  • Banked flex days to take off after crisis was over One person went on a sabbatical to refresh

My take

This was a great case study. Different than the ones you usually see. It’s helpful that the problem was an actual crisis and not an arbitrary deadline. The learnings were well distilled. Interesting answers during Q&A.

[kcdc 2025] Vibe Coding Revolution: How AI Assisted Development Tools are Transforming Velocity

Speaker: Tony Galati

For more see the table of contents


Intro

  • A Product Owner (Alex) at NAIC (National Association of Insurance Commissioners) gave the background of their project.
  • Origin: Gave a prompt for the backend/infrastructure and have Cursor generate the draw.io. Included Okta, Docker, etc. Showed the prompt. It’s about 20 lines and pretty detailed
  • Used prompts to make a front end prototype. PO iterated on it.
  • Then Tony spent about 2 days connecting them.
  • After that, they did a two day hackathon because knew could get something up quickly
  • At hackathon 1, learned need to have business problem, implementation plan and business support. Did two business days (9-4 each day)
  • Doing second hackathon next week.
  • Did daily standup at hackathon
  • Made sure had everything needed like Okta in advance of hackathon

Business benefits

  • Can generate use cases
  • If want specific format say it
  • AI rewrote his one sentence prompt to include depth needed
  • Got Next.jS front end prototype.
  • Business can iterate with prototype independently
  • Showed user stories generated
  • Even if don’t download code, will speed up time for business analyst
  • Figma.AI doesn’t let you change with prompts after initial generation. V0 lets iterate.

Back end

  • Switched speaker to Tony – Enterprise Architect
  • Absolutely not production ready, but could show working
  • Can specify to AI tool what coding standards to follow, needs to work on all devices, etc
  • Used Amazon Q first. Then started using Cursor
  • V0 is good for live changes in front of customer.

Before Hackathon

  • Engaged security and legal. AI acts on behalf of user so has user permissions.
  • Went through what the models were trained on: https://trust.cursor.com
  • Elaborated on AI policy. He did a show of hands and about 2/3 of the audience has an AI policy at work
  • Defined intellectual property allowed to be used in Hackathon. Could have called it a POC.
  • No PII data
  • Once commit code to Git, normal software development lifecycle.
  • Security engineer paired with developers to understand what Cursor can do
  • Setup Cursor IDE Project Rules – written in plain English. Had AI write it and human proofread. Can be context specific so can say some rules only apply when you say “commit” or other scenarios
  • Setup memory bank – includes extra info/tasks
  • Setup pipelines and quality gates
  • Wrote team prep instructions. Keep it short
  • Wrote down the tech stack. Team implementing used Angular so agreed to let Cursor translate.

Future

  • Roll out Cursor
  • Second hackathon
  • Smaller consumable guide/instructions
  • Mandatory walkthru sessions including BFF (backend for front end) pattern
  • Three days instead of two. This time using a language they aren’t familiar with instead of Angular.
  • AI first behavior – AI does a lot – ex: write tasks for AI consumption but human readable, our job will change towards steering AI. Have AI do one step at a time
  • No training because changes so fast. Instead pick champions and three day immersion
  • Buy things a year at a time since change so fast

Further future

  • AI code reviews.
  • Have multiple agents fix a defect and primary recommend what best
  • Future problem – new people won’t know codebase. Already have that problem and have to figure it out but won’t be worse. Will be catastrophic failures.

Key takeaways

  • Encourage staff to use AI – even at home. You need to fix the toilet, use AI
  • Start POCs
  • Visuals sell
  • AI is coming. Need to figure out how our jobs will change

My take

The speaker on stage was wearing a suit which made me nervous this wasn’t going to be technical. But he quickly said he was going to give an overview and turn it to Tony. Tony is wearing sneakers and jeans which is in keeping with what the hands on folks wear to conferences like this. The speaker in the suit asked how many people from the business side were in the audience. He made a joke that was that he expected when their were crickets. The information in both halves of the presentation was great. Excellent end oot the day. I’m glad the conference organizers gave them a big room! I also like that it was a realistic description and not “see AI is magic and does everything by itself”

[kcdc 2025] AI Vulnerabilities in 2025 – Some of the darker sides of AI

Speaker: Andreas Erben

For more see the table of contents


From the news

What drives model behavior?

  • Initial training
  • Fine puning
  • Potential customer fine tuning
  • System prompt – how the model should behave.
  • Data/prompt
  • Filters on data, prompts, output

Other links

My take

After the first example, there was a bunch of content on how LLMs work. I tuned out a little during that section probably because familar. Then it got interesting again.